From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Wed May 18 2011 - 13:26:55 CDT
Yes, but of course this does not mean that we don't need more support
in fonts. What this actually means is that font development should not
depend only on a few specialists, using costly softwares and extreme
knowledge as in the current situation when working with OpenType.
There's certainly a need for better tools, that are really open, and
less quirky to install on more platforms than just Linux (for free
tools).
But what is also missing is a way for users to correctly evaluate the
quality of fonts, and clean up their installations, and more easily
upgrade them or complement them, possibly by using composite fonts
(because almost all fonts have deficiencies and cannot be altered in a
interoperable way across systems, without infringing some property
rights).
The current font technologies remain a huge interoperability problem.
And I hope that some day, the OpenType specifification will be cleaned
up to mark the features that are no longer recommended, and those that
all new fonts should implement for macimu interoperability.
But I also hope that the OpenType technology will cover the domain of
composite fonts, allowing existing fonts to be used in an unmodified
way (without infringing rights) along with user-provided or
service-provided complementary data to fill the gaps). If it's not
possible, may be reinvent a new font development model that will be
really portable.
For now most fonts only concentrate on encoding their glyphs and
mapping them to a single character, but anything else (even if
excluding advanced typographic features such as kerning pairs and
hinting) requires too much knowledge and tuning work. Working on the
various font metrics and glyph metrics is still extremely tricky to
get consistant results, and all font developers still need to use a
lot of personal scripts to check the consistency of their work.
In fact, some alternate non-OpenType font formats that are easier to
work on already exist, but they are still proprietary to specific font
development tools, for easier editing, before converting them to
existing legacy font formats (which are supposed to be more compact,
but still costly and inefficient to decode in software, when a basic
general purpose compression scheme like .tar.gz or .zip, containing
the various tables as XML and tyiny SVG files in an open archive
format similar to today's MSOffice and OpenOffice documents, would
simplify a lot the development and complementation of existing fonts,
based on wellknown and stable standards.
Is there a subproject, in OpenOffice for example, to develop such font
format, most probably XML-based, and then standardize it using common
interoperable schemas, with a separate development of conversion tools
that will automatically generate the legacy OpenType and PostScript
formats tuned for various specific systems, instead of continuing to
add new quirky binary storages that are very difficult to extend
without adding new tables with contradictory contents between each
other ? Note that these conversion tools could as well be built
directly within system-specific renderers as part of their font
installation and caching tools and UI.
-- Philippe.
2011/5/18 Doug Ewell <doug@ewellic.org>:
> A somewhat shorter explanation:
>
> The comparison with existing Latin precomposed characters is not
> relevant. Almost all of those were added for compatibility with
> existing standards, as Philippe said.
>
> Text editing and processing with combining marks is not "very difficult
> and erroneous." The one use case that Plamen mentioned (a user manually
> deleting a base letter) is easily trained. Unicode has been around with
> this architecture for 20 years now.
>
> There are plenty of fonts that support Cyrillic base letters with
> combining marks. There are plenty that don't, especially older fonts,
> but on no account is it 99%.
>
> There is no great urgency to break stability and introduce duplicate
> encodings for Cyrillic text. All Cyrillic text can be represented using
> the existing architecture.
>
> --
> Doug Ewell | Thornton, Colorado, USA | RFC 5645, 4645, UTN #14
> www.ewellic.org | www.facebook.com/doug.ewell | @DougEwell
>
>
>
>
>
This archive was generated by hypermail 2.1.5 : Wed May 18 2011 - 13:29:31 CDT