41–50 of 172 posts
"If you're in Firefox or Chrome, it looks awful" Looks correct in Firefox 69.0.1 on Windows here. In Chrome it looks awful as described. In both the "bow" at the top overlaps the text on the previous line.
>Rendering text, how hard could it be? As it turns out, incredibly hard! Related undesired complexities/heterogeneities I encountered while implementing a simple text drawing API on top of various libraries (cf. "Pain points", near the bottom): https://github.com/jeffhain/jolikit/blob/master/README-BWD.m...
God yes. I'm building a UI design tool, and running head-first into this reality. I had no idea it was this hard.
- Code point is sometimes not enough to determine the glyph. For example, U+5199 must look different in Simplified Chinese and Japanese. Typically this is handled by using different fonts, but more formally it should be marked with different lang attributes (in case of HTML).
- Top-to-bottom writing mode is still pretty much in use in Japanese. HTML support is poor, but it's common in PDF. Caveat: Latin alphabets are rotated by 90 degree (as explained in OP), but for punctuations, simply rotating the glyph isn't enough because the center line is going to be slightly off. You need special glyphs for rotated punctuation.
- Unlike Latin scripts, most Chinese and Japanese characters are free to break line at any point, but there are exceptions: contracted letters (e.g. ちょっ) cannot be split. So you'll end up with treating each letter as a separate word. (Contracted letters are treated as one word.)
If it weren't for Windows, we could move on from TrueType outlines (.ttf) to CFF outlines (.otf). .otf works nicely on non-Microsoft rasterizers. It was terrible on XP. Now on Windows 10 it’s less terrible, but .otf fonts on Windows 10 using DirectWrite look bolder and blurrier than using FreeType, Apple, or Adobe rasterizers. If Microsoft adopted the Mac font rendering aesthetic and fixed their CFF rasterizer, we wo…
Earlier quoted context omitted.
You can't convert a bitmap back into vectors (well maybe image recognition of some sort). Once you render to canvas its a bitmap and stays that way all the way to printer. SVG is turned into the appropriate PS/PDF vector drawing command by the browser print engine, canvas just gets sent as a bitmap in the printer language since that all that's left. I believe pdf.js incorporated and modified https://github.com/gliffy…
Yeah, ok, so we have essentially PDF -> SVG -> PDF/PS because of too many abstractions. It would make sense to expose some internal printing API to the embedded PDF reader so all this nonsense wouldn't be necessary.
Printing is a forgotten corner on the web, would be nice if a mainstream browser implemented the full css print spec too so we could create page perfect output without relying on PrinceXml...
One man's antialiasing is another mans blur. I, for one, prefer crisp bitmap fonts.
I once tried to see the subpixel rendering using the Microsoft's magnifying glass tool. Got disappointed - the tool just disabled subpixel rendering. Globally, not just the area being magnified.
For the color example they say "here's what they look like in Chrome and safari"... and show some horrible mess, yet I'm on Chrome and that isn't what I see at all? The text I see looks fine, although the font is different. https://imgur.com/a/5JZVZCB
>3.2 Style Can Change Mid-Ligature >Here's what they look like in Chrome and Safari: Running 76.0.3809.132 here on Mac OS and it looks very different from the picture. Bug partially fixed? https://i.imgur.com/CcjATLO.png