From: Asmus Freytag (asmusf@ix.netcom.com)
Date: Wed Aug 29 2007 - 17:08:40 CDT
On 8/29/2007 2:20 PM, James Kass wrote:
> Asmus Freytag wrote,
>
>
>> There's no way the
>> application writer can rely on the font in that situation, short of
>> there being an additional agreement with *all* font vendors what a
>> "perfectly good" glyph is.
>>
>
> Generally, the application is *required* to use a glyph from the
> selected font, if the selected font has a glyph mapped with the
> character being called. The application must rely on the font --
> that's what fonts are for.
>
That's actually not the reality. And where application vendors have
deviated from that precept, it has often been done for good and solid
usability reasons - not the least of which is to work around
inconsistent implementations by fonts.
The vast majority of text handled on computers is not concerned with
fine typographical detail but with easy and problem free access to text
on screen.
> Asmus is correct, though, in this section. Applications can substitute pictures in lieu of font-specific control picture character glyphs. The choice is best left to the application designer. (T.U.S. 5.0 p. 508 for more detail.)
>
>
And the depiction of an unsupported VS falls into that realm; whether
the authors of TUS have managed to get around to spell that out or not
is immaterial.
>> We disagree about what is desirable behavior on fundamental level, I believe, so it's not useful for me to comment on the remainder of your message.
>>
>
> It can often be useful to identify points of divergence. It can help promote better understanding of two sides of an issue, for one thing.
>
> I wonder if we differ in the value we place on the importance of
> authorial intent.
>
If an author inserts a VS, the way the standard conceptualizes this, is
that he's *enabling* supporting implementations to show the difference.
If the difference is unsupported, it is *supposed* to be ignored (in the
ordinary case).
Therefore, the use of a VS expresses the authorial intent this way: "I'd
rather show this mathematical character with the other style of
negation, that the default, because I think it's clearer (or whatever).
So if your font can show this, here's a VS so it triggers the correct
glyph - but if your don't have the font, you'll still be able to read my
paper - it just won't show my preferred rendition of these characters".
The intent is NOT to start putting ugly symbols in the display of any
and all implementations that don't happen to support the VS sequence.
Such behavior is completely beyond the pale as far as the *reader* of
the text is concerned.
In and *editing* environment, e.g. a math editor, having a limited show
hidden mode that just reveals the VS, or just reveals any unsupported VS
characters would possibly be helpful - it allows the author to clean up
redundant and incorrect VS usage. (But a squiggly colored underline is
an equally appropriate method to show such keyboarding errors, and right
clicking could be used to initiate and automatic cleanup. The same
method could be used for redundant ZW(n)J, doubled SHY characters,
etc.). But this is the machine communicating with the *author*, which
serves a different set of requiremens than the machine transporting the
intent of the author to the reader.
The design of the VS is predicated on that it expresses *ignorable*
differences. Therefore, forcing it to become visible to all readers, by
default, is missing the point entirely. This is true whether it's an
unsupported one or and undefined sequence. Again, the only exceptions
are the show hidden modes, which provide a meta-view of the text.
A./
This archive was generated by hypermail 2.1.5 : Wed Aug 29 2007 - 17:10:48 CDT