From: John Hudson (john@tiro.ca)
Date: Sat Jun 17 2006 - 14:51:46 CDT
Kent Karlsson wrote:
>>>>Yes, and to solve the German problem you want to force
>>>>everyone else to perform this kind of text encoding hacks.
>>
>>>No, not at all. Only you seem to suggest that.
>>
>>Andreas did specifically say that if e.g. English users want
>>the form of opening quotation
>>mark used for U+2018 in Verdana then they should encode the
>>opening quote as U+201B. I'm
>>not just suggesting that. This is what he wrote:
>>
>> Actually, I have seen such quotation marks in English-language
>> books printed in Britain and the USA. But, as I wrote, they are
>> certainly not preferred. *If* you want such quotation marks,
>> then please use U+201B for them!
>
>
> I don't see any resemblance with what Andreas wrote and your
> (gross mis)interpretation.
Let's back up again then...
Type designers are making a decision about the form of the glyph for U+2018 based on
differentiating it from U+2019. There is a desire to be able to differentiate these two
characters, as opening and closing quotes in English and other languages, and this is
considered important enough by font developers to convince them to use a \ form for U+2018
when U+2019 displays, in the low resolution target environment for these fonts, as /. It
also has plenty of precedence in handwriting. Okay?
What Andreas is implying by his comments is that if one wants to differentiate these two
quote mark forms in this situation, one should encode the opening quote as U+201B
*If* you want such quotation marks, then please
use U+201B for them!
This seems to be his prescription for anyone who wants differentiated opening and closing
quotes in English faced with the particular design limitations of certain fonts and
rendering environments.
I am saying that this is no more a good solution than Germans having to use U+2019 in
place of U+2018 for the same purpose: to achieve a desirable glyph display.
This is a glyph display issue, not a text encoding issue. No one should be having to
change characters in order to get the glyph they want.
> As you say, applications tend not to implement that (for good reasons).
I am at a disadvantage because non-disclosure agreements prevent me from saying much in
response to this. Suffice to say, that the only reason I am aware of is application
developers having other priorities, but that I have already seen implementations in beta
and expect to see shipping support in upcoming releases.
> In any case, font setting is inherently fragile, and is therefore
> inherently unrobust.
And yet Unicode entirely relies upon and presumes font support for a huge variety of text
display issues including national and linguistic glyph preference (e.g. Serbian).
>>also differences to Sindhi shaping of some Arabic letters,
>>but there also seems to be
>>little interest from the user community in proposing these as
>>separate characters.
> ArabicShaping properties are normative, so if "shaping" here refers
> to joining behaviour one would either need to use ZWJ/ZWNJ or
> some other ("new") characters. It is NOT a matter of some fonts
> implementing different joining behaviour. (If "shaping" here refers
> to something else, then please say what it refers to.)
In this context, it means that the normal glyph shape for the final form of U+0647 in
Sindhi differs from the glyph shape for the Arabic use of the same letter. So if one has a
font for multilingual use, one needs a mechanism to affect a Sindhi-specific subsitution.
This is the sort of issue we deal with in font development every day. It is the inevitable
results of the Unicode character/glyph distinction, and is one of the things that OpenType
was specifically designed to accomodate.
John Hudson
-- Tiro Typeworks www.tiro.com Vancouver, BC john@tiro.ca I am not yet so lost in lexicography, as to forget that words are the daughters of earth, and that things are the sons of heaven. - Samuel Johnson
This archive was generated by hypermail 2.1.5 : Sat Jun 17 2006 - 14:56:01 CDT