Re: How to Add Beams to Notes

You cannot cover a full plane with a single font. There are other factors
such as total size the also limit severely their use. We have to live with
the limitations of OpenType. In addition a giant font is hard to maintain,
version and update without breaking usages.

Font auhtors should focus their efforts on separatings scripts within a
collection a collection of related fonts (like what the Noto project did):
the rest will use font linking (which can be and already is used by
renderers, and can also be parametered by users for accessibility, or to
use prefered variants in some domains).

Also not all scripts have the same kinds of style variants
(serif/sans-serif, 2 or more distincive weights, straight/italic/oblique,
plain/hollow/shadowed), and trying to synthetize these styles will break
the nature of the script (notably for many symbols): you'll need separate
fonts for separate styles for specific scripts, other scripts may support
synthtic styles or not alter at all their rendering.

Code2000 is then just useful as a last resort font, but its glyphs are
still very poor compared to other fonts, and the fact it uses the same
font-wide strategy for hinting also creates lots of caveats: you cannot
hint Sinograms like Latin or Greek and symbols have their separate
requirements (notably geometric shapes and line drawing).

Finally the bad thing about Code2000 is about font metrics, notably
baselines: while you want to unify these baselines and line-heights, you'll
reach the point where some scripts are ridiculously too small or improperly
aligned: its much easier to separate them and tune these metrics
separately. Trying tro fix these metrics for one script will break another
one in that font, and finally you cannot create a comprehensive coverage
test and get stable results because there are contradicting objectives for
different uses: it's much easier to conciliate the possible choices by
separating scripts, so that you can more easily create additonal variants
for a few of them, and then create a separate rendering engine which will
use some parametered rules for selecting the most appropriate fonts. Adn
then it's much easier to update only one of these fonts when there are
improvements, without breaking all the rest.

2017-05-04 9:26 GMT+02:00 Richard Wordingham via Unicode <
unicode_at_unicode.org>:

> On Thu, 4 May 2017 05:01:17 +0200
> Philippe Verdy via Unicode <unicode_at_unicode.org> wrote:
>
> > Rendering Devanagari with OpenType does not require any PUA
> > assignment in that font for variants. The sequences are mapped
> > directly using subtables and the rules defined in OpenType for that
> > script. Fonts just use their own internal glyph ID's without having
> > to assign them any Unicode mapping, using Glyph processing rules.
>
> > Same remark about Arabic (though some encoded compatibility
> > characters will map to some of these glyphs... without using any PUA).
>
> The OP's plan is to use one font for the BMP, one font for the SMP, and
> one font for the rest. However, the BMP font Code2000, which only
> goes, incompletely, up to Unicode 5.2, uses 63,546 glyphs, which is
> very close to the limit of 65,535. There is the slight margin that it
> included a few small scripts with standardised (ConScript
> Unicode Registry) PUA allocations.
>
> Richard.
>
Received on Thu May 04 2017 - 07:52:08 CDT