Hi,
Octocontrabass wrote:
So, in other words, it can only render text for which there is a direct 1:1 correspondence between glyphs and code points.
You should really read the documentation.
It does not render text. It renders glyphs, because
it is a font renderer, not a text renderer. And there is no direct 1:1 correspondence between glyphs and code points. Never was.
What you have meant I think, is that SSFN's supported encoding is and always will be ISO-10464, and you always get the same glyph for the same character with the same font? Because there was only a guaranteed correspondence between code points and glyphs but not between glyphs and code points. But that's for the past, because since yesterday I've implemented glyph variants, to support Serbian / Macedonian Cyrillic B D G P T letters in Italic style.
But still, within a variant lookup table, you'll get exactly the same glyph for the same code point, but nothing says that the same glyph can't be returned for a different code point too. Actually this is a very important feature that SSFN utilizes for it's geometrical compression algorithm. What do you think, how on earth can it compress a 64k BitStream Vera TTF into a 15k SSFN otherwise?
![Smile :-)](./images/smilies/icon_smile.gif)
Octocontrabass wrote:
Are there any plans for your converters to expose context-sensitive glyphs in some way, so that there's less manual work required for complete Unicode support?
I'm not planning to change the current behavior, because:
- First, current font formats does not have such information either (there's no place for them in PSFU, BDF, PST1, TTF fonts, and freetype2 does not expose OTF's many different alternative and replacement tables in a single meaningful way, not to mention that neither Uniscript nor Apple renderer can't use those tables properly either, read FontForge's doc)
- Second, it is completely wasteful to store such an information in a font file because a specific UNICODE code point has to be translated to the same corresponding isolated, initial, medial, final UNICODE code points regardless if the font is Serif, Sans, regular, oblique, bitmap, vector based etc. Same stands for UNICODE code point combinations (VS included). If UNICODE hasn't allocated a code point for that letter in a particular context, then you can always use Supplementary and Private Use Areas until they do.
- Third, it's totally absurd and irrational to expect full UNICODE
text rendering capabilities from a simple
font renderer that's aim is embedability and extra small code size (ca. 20 kilobytes, man!).
- Fourth, why should I bother at all when there are excellent OpenSource libraries to do exactly that? I mean if you want
complete UNICODE support, you can use Pango for example. You always forget about Pango.
Cheers,
bzt