Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Typesetting Engines: A Programmer's Perspective

blog.ppresume.com

Post reply on HN
Print view View original

51–55 of 55 posts

Re: Typesetting Engines: A Programmer's Perspective

#51

Post by Aaron2222 »

__mharrison__ wrote: post #33
endgame wrote: post #14

Earlier quoted context omitted.

Typst looked promising, but the very first thing I wanted to do with it - generate some slides with code snippets, and use highlights to call out specific features of the code - is not possible. The core layout engine seems to merge `styled(...)` spans in code blocks far too aggressively, making it impossible for codly (the code highlighting package I tried) to pick out precise ranges to highlight. I went back to bea…

Did you file an issue? The devs are quite responsive and now is the time to act while it is making quick progress.

They did[0] (as per their earlier reply[1]), and now it's fixed.

[0]: https://github.com/Dherse/codly/issues/35

[1]: https://news.ycombinator.com/item?id=42103510

Re: Typesetting Engines: A Programmer's Perspective

#52

Post by chearon »

chrismorgan wrote: post #36
chearon wrote: post #27

Earlier quoted context omitted.

Paste the following into https://chearon.github.io/dropflow/ to see that it _is_ possible to style individual Arabic characters in canvas: ع ر ب ي That uses harfbuzzjs to do shaping and, for the segments that it has to, it paints paths instead of using fillText. There is an even better method which Mozilla's pdfjs uses: for all the glyphs that you want to draw, build a font (easy with HarfBuzz) that maps sequential c…

Sadly that doesn’t work with Indic text. Take for example, my name: క ్ ర ి స ్ Ideally it’d render about the same as my manual splitting/colouring: https://temp.chrismorgan.info/%E0%B0%95%E0%B1%8D%E0%B0%B0%E0... . Now sometimes you can colour parts differently: if you stick with the inherent vowel on a conjunct, here making it LETTER KA, SIGN VIRAMA, LETTER RA, ditching the VOWEL SIGN I, then essentially the K from…

That's because Noto Sans Telugu (the font dropflow automatically downloaded based on the text; doesn't seem like a great pick but not wrong?) is returning ligatures. Not all fonts will be able to support styling individual characters. I get the same results in the dropflow playground as I get in Firefox and Chrome [1]. Maybe you were using different fonts in those browsers?

You might be able to turn OpenType features off in those browsers to make it look like your manual coloring, I'm not sure.

> if you stick with the inherent vowel on a conjunct, here making it LETTER KA, SIGN VIRAMA, LETTER RA, ditching the VOWEL SIGN I, then essentially the K from KA and the A from RA will be coloured LETTER KA, and the R from LETTER RA will be coloured SIGN VIRAMA. I haven’t decided yet if that’s an improvement!

Maybe because it changes the shaping results? I don't know enough about the writing system to understand this yet :)

[1] https://jsfiddle.net/fz15xu20/

Re: Typesetting Engines: A Programmer's Perspective

#53

Post by chearon »

rikroots wrote: post #44
chearon wrote: post #27

Earlier quoted context omitted.

Paste the following into https://chearon.github.io/dropflow/ to see that it _is_ possible to style individual Arabic characters in canvas: ع ر ب ي That uses harfbuzzjs to do shaping and, for the segments that it has to, it paints paths instead of using fillText. There is an even better method which Mozilla's pdfjs uses: for all the glyphs that you want to draw, build a font (easy with HarfBuzz) that maps sequential c…

> Google has proposed a placeElement method that allows you to render HTML and CSS into a canvas I've just read it. Oh, dear ... what an awful proposal! My initial thoughts, reacting to the README at https://github.com/WICG/canvas-place-element > There’s a strong need for better text support on Canvas. [...] This includes not only visual features but also the possibility of supporting the same level of user interacti…

Interesting take on representing charts in an accessible way. I feel like, as web developers, we were fed a myth that lots of markup and attributes automatically makes your content accessible. But it takes more thinking than that.

I've taken a similar approach to layering canvases with normal HTML (typically the HTML is on top). I don't have a problem logically representing what's painted on the canvas and doing my own hit detection either. Shaders and text shaping in canvas sound a lot more attractive to me than placeElement, but I guess we'll see. I should get around to campaigning for ctx.shapeText and ctx.fillGlyphs but I don't know how much folks care about it.

Re: Typesetting Engines: A Programmer's Perspective

#55

Post by zvr »

liendolucas wrote: post #37

Surprised that groff is not mentioned. I've recently used it to typeset my CV and oh boy... It feels like something really really arcane. Despite fighting with it at the beginning I'm quite happy for the result and also like that I can now version the code (no more LibreOffice for that). The key difference between typesetting and textprocessing is that typesetting is like programming a document, you have basically ac…

Having used many *roff variants (e.g., troff, nroff, ditroff, groff) over decades and also having rather extensive experience with LaTeX, I'd now definitely choose the latter for any serious typesetting task.

Pain points include many customization points: re-creating exact document specifications provided externally, using specific typefaces, creating your own macros... Oh, and leaving ASCII (or ISO-8859-1) for multi-script characters. These are not blocking points (there are ways to overcome them, if you find the solutions), but are still major pains.

Today's groff is a very fine software, if you are satisfied with its default settings and your task is in the domain it handles.

Post reply on HN