2015-05-24 11:25 GMT+02:00 Richard Wordingham < [email protected]>:
> There is another solution, which is *bad* but can work well for a short > period. That solution is for a font to hijack a code point with the > desired properties relevant to rendering. > It is not so bad when the usage is limited to some documents using specific fonts designed for this purpose. OK it is not fully interchangeable, but it can be good for the start (including for creating documents showing the proposal for a new encoding). However if we want to limit the propagation of this "bad" encoding in documents not specifically linked to a specific font, a good solution is to embed that font directly in the document (the PDF format is suitable for that, but you can also do that with HTML documents using embedded SVG images, which can themselves be embedded in SVG fonts embeddable in the document itself). No need to use a variation sequence (unless it is also recognized spcifically in that embedded font) But it is not general enough for all complex scripts that require specific layout rules (GSUB/GPOS), notably when they are contextual. In summary we come back to the use of collections of glyphs (SVG) without actually any text rendering engine. With HTML5, the embedding of SVG is greatly facilitated (and can also be automated with some custom javascripts transforming an easily compable syntax into a sequence of text and images). You can even apply some limited CSS styling that can apply to both the text and inline SVG images, provided your SVG is designed to be scalable within the current text line metrics, for example when it uses a "viewport" attribute but not the "width" and "hight" attribute that should be set by the default HTML box model: it will work however reliably only for full clusters occupying the standard line height and vertical alignment relative to the baseline, not for individual characters if they are combining or using some contextual layout). Now it's up to you to invent your own syntax for making the transform into sequences of plain-text and inline images). However you won't get some font-specific features such as hinting for small font sizes (SVG fonts currently have no standard way to include hinting instructions in order to transform the geometry of paths according to the physical device, and there are also difficulties with the specification of sizes in CSS, for example on Hi-DPI displays such as smartphones, or with the zoom in/out feature of browsers: it requires fine tuning not with the CSS "logical pixel" unit, scaled in logical "dpi", but with the newer "ddpx" unit, plus some other metrics related to subpixels of the rendering surface, or relative alignment of pixels with the physical positions, which are not necessarily in a simple grid, but mapped using "screening" technics which are very common when printing). As far as I known "font hinting" is still a work in progress (since long), it is also very complex in TrueType/OpenType and has no real standard (only a few specialists can use it to design specific fonts and it is not easily reusable elsewhere), so nothing in this domain is supported by SVG fonts (for small font sizes the current solution is still to use bitmap images instead, assuming that the HTML rendering engine is using its best efforts to map the logical pixels of bitmaps into physical pixels or subpixels on the rendering surface, and to preserve their intended color gamut and contrasts without excessive distortions); in fact TrueType/OpenType or SVG and CSS does not even have any decent support for "screening" technics, like those that exist in PostScript since several decennials; and for this reasons, publishers still **love** PostScript for the fine tuning of the typography and images and for getting the best final result that the final printing medium can support. So PostScript fonts are definitely not dead, but still not enough supported and used for display due to lack of equivalent support in OSes and browsers (even in HTML5, there's still no decent support in the newest "canvas", that still have lots of quirks at this level, and that also don't support any suitable screening). And most popular printers do not even have Postscript (it is replaced by some capabilities of the printer drivers doing all the work, via the more limited graphic APIs of the OS used by applications: those printers only support simple bitmaps). It is then still difficult to create for the widest range of devices any document elbedding simultaneously plain-text rendered with fonts, scalable images (such as SVG), and bitmap images (including photography), without first assuming some physical properties of the rendering surface (but also taking into account local preferences of the final user, such as zoom level, or colorimetric profiles, or choice of paper and print quality, or multiple displays). The "WYSIWYG" concept is just an advertized goal, but still a myth as it is largely not implemented or supported.
