141 points | by todsacerdoti3 days ago
Yet, the optical margin correction looks mechanistic and only concerned with symbols, not with characters: The "Y" at the start of the first line doesn't move a bit, even though it's clearly optically too light on the left. The next three lines all start optically pretty heavy with a bar. So I'd nudge to "Y" to the left.
I think it's just a pity that LaTeX with microtype is still the pinnacle of automatic typesetting, after all these years. I really enjoy good typography, but the Web, App and even Desktop world seems not to care about such details, apart from a few programs like Ableton.
My free, open-source, desktop text editor, KeenWrite, integrates my quote curling typographic library, KeenQuotes. KeenQuotes curls straight single quotes, double quotes, swaps in the multiplication symbol, corrects low opening double quotes (,,), and handles numeric primes, all while respecting code blocks. KeenWrite replaces some ligatures, but proper ligatures need to account for etymology, which has no simple solution. (Aside, even curling straight quotation marks properly requires part-of-speech processing.)
KeenWrite[1] exports to text, XHTML, or PDF files. Architecturally, the XHTML format doubles as an XML format that is passed to ConTeXt[2] for typesetting into PDF. ConTeXt developers care deeply about typography.
I have only a tyro's appreciation for typography, so please forgive my uninformed question. Is it a pity that LaTeX+microtype is the pinnacle of automatic typesetting because it's not good enough, or because it's non-web-focused and there is no web analogue of equivalent quality?
Also, the full feature set of microtype is only supported with (Pdf)LaTeX, but not with the newer XeLaTex, meaning that in order to get your favourite fonts to work with PdfLaTex, you have to do a hilarious amount of work to translate an OTF font into specific cuts in MetaFont, the LaTeX font format, and so on.
I mean, I understand that things get pretty tricky once you try to integrate such schemes into a font renderer. There's other scripts than just Latin, with probably very different rules, there are different font sizes, text sizes, etc. A lot of variables to take into account. A lot of variables that were constants when typesetting on a page. So the problem is now more complicated than in the past.
Now, their education website(s) ... that stuff is gorgeous, and I think does represent somebody's typographic imagination, to the extent that HTML/CSS makes it possible (which is .. a lot).
It's better today (both for the above issue and also for usability) to disable the ligature substitution and let browser engines manage ligature replacement.
Browser search can typically parse Unicode ligatures, so it's not a huge usability problem. But saving, copying, or scraping the output and using tools that don't process ligatures into their component letters will fail.
This also (very slightly, but still notably) abuses empty contentless <span>s to inject space through CSS margins.
Also, the attempt to brute-force small caps by applying a font subset via a span doesn't work at all for me, in either Chrome or Firefox.
It's a good effort, but I also can't think of a use case where the result is worth what this does to the markup.
Maybe this might help people with dyslexia but don't proper dyslexia focused fonts and aids exist already?
Now, I am completely aware there is nothing behind this other than my visceral reaction. I do not know you at all. I share it only to communicate that to somebody with my background it is an obvious and fundamental improvement.
Most people who have made a website with CSS before would at best change the font size, the line spacing and the font face and tweak it to a point that feels easily readable and call it a day. Introducing variable widths between the characters of the font, digraphs and so on feels like more like exercising artisanship that only the experts would see value in rather than solving a technical problem.
Perhaps advanced web design/typesetting is the main application of this and it has a chance of inducing a better subconscious effect on the viewer. Sort of how magazines and books were designed back in the day I suppose.
I'm curious but have you ever heard of anyone that works as a programmer that has not been especially keen on linting and testing (as in automated testing)?
I thought that examples of not being overly keen were quite abundant.
And it is often lamented on this site about how much work it is to get even people who have made a small to medium sized project and have the word programmer or developer in their job title to actually want to do linting and testing.
So what I'm saying is that at least for linting and testing yes, these really might seem like
>exercising artisanship that only the experts would see value in rather than solving a technical problem.
I get that it helps people who are collaborating on large codebases. But to me, typography is orders of magnitude more important, because it’s facing the end-user.
Same as linting and refactoring, then.
No one wakes up in the morning, looks in the mirror, and says, "I want to use an application build with React, has no tech debt, and has great commit msgs...".
I'm not suggesting the tech and stack don't matter. They do. But they are a means, not the ends. The sad fact is, the ends aren't - from the users' POV - noticeably better. More bloated? More buggy? Probably.
Whether this tool makes it “better” is another question. I tend to think there are general rules for “better” typography but when you get to the details, it depends on the individual and how they perceive and process information. One friend who is ADHD likes very cramped text which looks jumbled and messy to me, making it difficult to pick out individual letters. If the before case looks better for you, that’s a valid criticism.
- Justification is not there and it just looks bad.
- Paragraph width is arbitrary, which makes reading some emails (from folks who apparently think the earth is not only flat, but 1D) awful to read. I'm shown a 2000px+ wide, 60+ word line for a message.
- Long words or non-English destroy line breaks and lines break at odd places.
- There's widows and orphans around. I think I didn't even saw this one until I was told to fix my stuff during peer review, but now I see it everywhere and it only took a couple minutes to explain the issue and kind of ruin me.
- Non-english keeps breaking the web.
- Probably not just on typography, but many websites are still unable to deal with not so special characters like á, à, ä ø, £ and you get to read gibberish.Which is totally great! The world needs lots of 0.1% improvements because 100's of them can add up to make something look or feel better when applied at the right time in the right way.
If you work with monospace terminal/code/markup a lot, you are probably very used to seeing " . But it is definitely well established that “ is appropriate for human text, Word has automatically corrected this for many years.
Besides, I think this is cool. Someone saw a problem and solved it. I think it looks better too. Now, if only italics were properly spaced from normal text... but that's available in CSS.
- https://developer.mozilla.org/en-US/docs/Web/CSS/hyphens
- https://developer.mozilla.org/en-US/docs/Web/CSS/word-break
Edit: I missed that on the top of the page there's an example section on a second column which is not responsive.
They are ripe for any sort of typographic improvement --- the only things which keep me reading on my Kindle are the convenience and the ability to report errors.
But I wouldn't mind having such a feature built-in in browsers if it brings value to other people.
You can easily tell some sites are unresponsive or Chrome-only.
I see adapting parameters like size, measure, and line height to different screen sizes (and the related reading distances) as one of the main challenges of web typography.
Not as sophisticated of a project but I've tinkered with a stylesheet to address some of these issues here: https://pglevy.github.io/typeset.css/