Re: Regarding Unicode for new Symbol

2015-05-24 11:25 GMT+02:00 Richard Wordingham <
richard.wordingham_at_ntlworld.com>:

> 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.
Received on Sun May 24 2015 - 13:53:59 CDT