41–50 of 55 posts
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…
For me, I think groff/LaTeX/SILE/typst all belongs to same category, i.e, the author write some markup language, then processed by some processors, then get an output. I chose LaTeX and Typst as the classic ones in my post:
- LaTeX is the classic, old school typesetting engine - Typst, clearly more modern, with many advanced design like incremental compilation, wasm and web app, instant preview, better error message.
For others, groff/SILE, to be honest I don't have time to dive into each of these.
----
Do you see any advantages of groff over LaTeX?
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…
The most painful issues I encountered when building out a text layout engine for my JS 2D canvas library were: - Vertical text - in particular when it comes to how CJK punctuation differs in horizontal and vertical environments (not yet solved) - Staying on CJK, making sure the punctuation marks that follow a character don't break and remain with their preceding characters at all times. (I expect the same holds for o…
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…
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 interaction as the rest of the web
Agreed, but ... adding HTML/CSS to a raster (or WebGL etc) image is not the way to do it. I much prefer your idea of incorporating HarfBuzz-like functionality into the canvas/text APIs - especially given that HarfBuzz is included as part of most browsers' code base.
I've played with mixing HTML/CSS with canvas in my canvas library. The results are ... interesting[1][4], but (probably) not the ideal solution. Making it easy for developers to build canvas interactions with HTML/events anywhere on the page is much more productive and useful[2].
> There is currently no guarantee that the canvas fallback content currently used for accessibility always matches the rendered content, and such fallback content can be hard to generate.
My thinking is that directly reflecting the canvas text back into the DOM is often not useful for people using screen readers. They don't need to hear every number on the chart axis when instead they could be presented with just the measure and range of the axis. If the HTML element rapidly/repeatedly updates its content, it's going to be a very unpleasant experience for the user. I've experimented with this sort of thing in [2], but need feedback from real screenreader users to understand if the solution meets their needs.
> Access to live interactive forms, links, editable content with the same quality as the web. This will help to close the app gap with Flash.
Flash is dead. Please leave its bones in the crypt.
> A limited set of CSS shaders, such as filter effects, are already available, but there is a desire to use general WebGL shaders with HTML
I only work with 2D canvas, but I can understand the desire here. A different approach might be to convince browser devs to work on improving SVG (and CSS) filters to support WebGL shaders, which can then be used by the canvas? Though Safari still doesn't support using SVG filters in the canvas so maybe convince them first?
Playing with filter effects is one of the joys I get from working on my canvas library[3] - but that's got nothing to do with text layout ... except when applying the filter to text, of course![4]
[1] - Use stacked DOM artefact corners as pivot points https://scrawl-v8.rikweb.org.uk/demo/dom-015.html
[2] - London crime charts https://scrawl-v8.rikweb.org.uk/demo/modules-001.html
[3] - A gallery of compound filter effects https://scrawl-v8.rikweb.org.uk/demo/filters-103.html
[4] - Editable header text colorizer and animation effect snippets https://scrawl-v8.rikweb.org.uk/demo/snippets-006.html
Earlier quoted context omitted.
I firmly believe that just its name set TeXmacs back by a lot. It's a pretty great choice, was even more so a decade or two ago (when typst and the ilk weren't available). But every single time I've tried to introduce it to someone, it's always some variant of "Oh, I don't use Emacs, so a plugin for that isn't useful to me". It's a really unintuitive and unfortunate naming choice that I wish they'd at least changed a…
Any idea about TeXmacs support for non-latin languages?
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…
I know groff, at least the bible K&R C programming book is published by groff, if I am not wrong. For me, I think groff/LaTeX/SILE/typst all belongs to same category, i.e, the author write some markup language, then processed by some processors, then get an output. I chose LaTeX and Typst as the classic ones in my post: - LaTeX is the classic, old school typesetting engine - Typst, clearly more modern, with many adva…
Earlier quoted context omitted.
My understandings, as one very familiar with Indic scripts, very familiar with Unicode in general, but not a CJK user , so please correct me if I’ve blundered: • Indic scripts need the renderer to support complex text shaping, or else the text will generally be illegible, as though you were drawing your letters wrong, stacking some vowels on top of each other, and other nonsense things like that. As an example, if yo…
> CJK line breaking is awful It's not true for Chinese. Chinese allows line breaks after any characters.
Earlier quoted context omitted.
My understandings, as one very familiar with Indic scripts, very familiar with Unicode in general, but not a CJK user , so please correct me if I’ve blundered: • Indic scripts need the renderer to support complex text shaping, or else the text will generally be illegible, as though you were drawing your letters wrong, stacking some vowels on top of each other, and other nonsense things like that. As an example, if yo…
That graphic of the Indic glyph is very interesting! Definitely explains why shaping is so complex for those scripts! Regarding CJK line-breaking, my understanding was that it was only Thai and closely related languages that required dictionary-based line breaking, and the Chinese/Japanese had simpler rules mostly concerning punctuation. But I'm not certain about that.
So _this_ must be why the Affinity suite doesn't properly render Devanagari, yet Inkscape can.
Earlier quoted context omitted.
And Greek alphabet is sort of a base for both major groups of European alphabets, Latin and Cyrillic. Can we just say greek-based alphabets?
Let's just go further back, and say Egyptian hieroglyph derived.
So egyptian it is.