Re: Unicode WYSIWYG = WYSIWYS campaign
Re: Unicode WYSIWYG = WYSIWYS campaign
- Subject: Re: Unicode WYSIWYG = WYSIWYS campaign
- From: Henrik Holmegaard <email@hidden>
- Date: Sat, 6 Mar 2004 18:37:20 +0100
Let's skim the technology situation, without dipping our feet too far
into the deep and dark waters of character encoding, glyph ordering and
the PDF Specification.
First the workflow rule : Export directly to PDF and do not stream
PostScript for conversion by Distiller. This applies both in color and
in text management.
Hopefully, everyone understands that PostScript 3 does not support the
ICC file format for object-level color management, whereas PDF 1.3+
exported directly does.
For object-level text management the Unicode source character string
and the rendered glyph order can be embedded when PDF is exported
directly.
When application software translates its internal data structures into
PostScript, the glyph array and the glyph geometries are streamed, but
not the source text string.
It is still possible to map say from glyph PostScript names to Unicode
characters, but it is preferable to have the Unicode string itself.
In InDesign 3 you will note that with a bug free OpenType font, what
you can search as semantic characters in the layout is what you can
search as semantic characters in exported PDF. The Unicode text string
is the same, in the layout and in the PDF.
Second the technical history : In sequence MacRoman was followed by
MacExpert which apply a 1:1 relationship between code point and glyph
order.
For instance, in MacRoman there is a code point for the fi ligature and
in Adobe Type 1 and Apple TrueType Simple there is an fi ligature.
To set the ligature you type a keyboard shortcut. Essentially it works
just as in Gutenberg's composing case, that is, entirely manually.
However, this approach means that for every required ligature in every
Western European language, you need to create a larger standard
encoding table or create a house-version of an existing encoding table.
This approach is self-defeating, as is self-evident. The reason is that
English is only one of the Western European languages, and the
ligatures required for English typography are insufficient for
languages other than English.
And it quickly gets worse because there are writing systems which
resist modularization and mechanization as their glyph ordering is
complex and contextual.
The Apple TrueType Advanced Specification, and the subsequent OpenType
Specification, both sever the link between the character string and the
glyph order.
As long as the link remained, complex glyph orders had to be hardwired
into the character encoding which led to a breakdown of text processing.
The solution is to make sure the character encoding stays a constant,
and to apply glyph ordering in a separate processing level using line
layout tables.
This way glyphs can be added to fonts depending on the needs of the
design (calligraphic flourishes link glyphs for arbitrary code points)
and the langauge (Danish, Dutch etc where the glyphs that need linking
can be looked up in a standard spelling reference) without ever
modifying the character code table.
The difference between the two specifications is that for OpenType the
source character string is required to be Unicode.
It is easiest to understand text management if Unicode is described as
a text connection space just as CIE is described as a color connection
space.
The technology of text management is backward compatible in the sense
that if the font maker and the font user have applied legacy encodings
as specified, the glyphs will map to the specified legacy code points,
and the legacy code points will map to Unicode, no problem. But most
professional fonts do _not_ follow the specified code points and most
design, IT and marketing professionals have 50 Mb to 150 Mb of legacy
fonts, most unregistered and many with broken encodings.
The problem is that the printed-oriented WYSIWYG approach of the past
two decades has caused a predatory "hand us your outlines and forget
licencing" attitude to the font foundries, both large and small. The
font foundries need to be able to reconstitute their business models to
provide for updating routes, and the user community needs to register
and update its font software. A professional font is no less an asset
than a professional profile, perhaps more so.
As bandwidth goes up on the web, and as Adobe fixes the RGB workflow,
we need to be able to position RGB _once_ in InDesign and export to
high resolution print delivery and low resolution screen delivery on
the fly. And if logo type in an RGB PDF is not searchable, I am certain
that clients will complain louder than if the logo color is off. There
is nothing that infuriates the business-minded of this world as much as
not being able to be found in the virtual community. And please believe
me when I say that one does not find PDF content by CIE co-ordinates.
Thanks,
Henrik
_______________________________________________
colorsync-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/colorsync-users
Do not post admin requests to the list. They will be ignored.