[mpeg-OTspec] Suggestion for minor correction on figure styles [1 Attachment]
Sairus Patel
sppatel at adobe.com
Tue Mar 30 01:15:28 CEST 2010
Vlad: I've reviewed the 'kern' table section changes, and they look good. Thanks.
All: Just so we're all on the same page, could someone please describe the process by which these changes will make their way into the OT (as opposed to the OFF) spec?
Best,
Sairus
From: mpeg-OTspec at yahoogroups.com [mailto:mpeg-OTspec at yahoogroups.com] On Behalf Of Levantovsky, Vladimir
Sent: Monday, March 29, 2010 3:48 PM
To: David Lemon; mpeg-OTspec at yahoogroups.com
Subject: RE: [mpeg-OTspec] Suggestion for minor correction on figure styles [1 Attachment]
[Attachment(s) from Levantovsky, Vladimir included below]
Dear all,
Please see attached the proposed changes we discussed reformatted in ballot comments template form. This document combines the "kerning" changes we discussed earlier with the most recent feature descriptions.
I rearranged the text suggested by Thomas into separate pieces that are specific to each particular paragraph of the specification. The highlighted portions show the current text that is being modified, and the underscored text shows the proposed changes and additions.
Please review this document for accuracy and completeness, and provide your comments. If I do not hear from you until the end of the day of March 30 (tomorrow), I will (with my "member of US delegation" hat on) ask US Secretariat to submit these comments to ISO. Members of AHG that represent their respective National Bodies and wish to do the same can submit these and/or any additional comments through their National representatives.
Thank you,
Vladimir
From: mpeg-OTspec at yahoogroups.com [mailto:mpeg-OTspec at yahoogroups.com] On Behalf Of David Lemon
Sent: Friday, March 26, 2010 8:50 PM
To: mpeg-OTspec at yahoogroups.com
Subject: Re: [mpeg-OTspec] Suggestion for minor correction on figure styles
As the culprit behind the current wording, I'll second Thomas'
proposed clarifications (along with Valdimir's subsequent
clarification). Back when I wrote this stuff, we held a strong
assumption that the default figures would be lining in style and
tabular in width. We still follow that practice, and recommend it as
the safest default - but that's no reason for the spec to fail to
allow for other approaches.
- thanks,
David Lemon
Sr Manager, Type Development
Adobe Systems, Inc.
408 536 4152
lemon at adobe.com<mailto:lemon%40adobe.com>
At 13:50 -0700 3/26/10, Thomas Phinney wrote:
> >From a conversation between me and John Daggett of Mozilla, on a CSS
>mailing list. He wrote:
>
>> OpenType spec just says "Users can switch between the lining and
>> oldstyle sets by turning this feature on or off."
>>
>> I think that may be a bug in the spec, if a designer uses old-style
>> figures as the default glyphs for numerals then the statement above
>> will be incorrect.
>
>He is of course correct. Further, the default figures in a typeface
>may be neither lining nor oldstyle, but in between or something else!
>To allow for default figures that are non-lining, or even neither
>lining nor oldstyle, I have made a more formal proposal out of my
>response.
>
>Currently the 'lnum' and 'onum' feature tags in 6.4.3.2 "Feature
>descriptions and implementations," include the following language
>(assuming they are the same as the current OT spec).
>
>LNUM
>
>Function: This feature changes selected figures from oldstyle to the
>default lining form.
>Example: The user invokes this feature in order to get lining figures,
>which fit better with all-capital text. Various characters designed to
>be used with figures may also be covered by this feature. In cases
>where lining figures are the default form, this feature would undo
>previous substitutions.
>Recommended implementation: The lnum table maps each oldstyle figure,
>and any associated characters to the corresponding lining form (GSUB
>lookup type 1).
>Application interface: For GIDs found in the lnum coverage table, the
>application passes a GID to the onum table and gets back a new GID.
>Even if the current figures resulted from an earlier substitution, it
>may not be correct to simply revert to the original GIDs, because of
>interaction with the figure width features, so it's best to use this
>table.
>UI suggestion: This feature should be inactive by default. Users can
>switch between the lining and oldstyle sets by turning this feature on
>or off. Note that this feature is distinct from the figure width
>features (pnum and tnum). When the user invokes this feature, the
>application may wish to inquire whether a change in width is also
>desired.
>
>
>ONUM
>
>Function: This feature changes selected figures from the default
>lining style to oldstyle form.
>Example: The user invokes this feature to get oldstyle figures, which
>fit better into the flow of normal upper- and lowercase text. Various
>characters designed to be used with figures may also have oldstyle
>versions.
>Recommended implementation: The onum table maps each lining figure,
>and any associated characters, to the corresponding oldstyle form
>(GSUB lookup type 1).
>Application interface: For GIDs found in the onum coverage table, the
>application passes a GID to the onum table and gets back a new GID.
>UI suggestion: Users can switch between the lining and oldstyle sets
>by turning this feature on or off. Note: This feature is separate from
>the figure-width features pnum and tnum. When the user changes figure
>style, the application may want to query whether a change in width is
>also desired.
>Script/language sensitivity: None.
>Feature interaction: This feature overrides the results of the Lining
>Figures feature (lnum).
>
>
>I hereby propose those sections of these two feature descriptions be
>replaced as follows. (Note that this also corrects a typo in the
>"lnum" application interface description, where onum was incorrectly
>referenced. Note also that there are parts both before and after the
>blocks I am amending, which can remain untouched.)
>
>
>LNUM
>
>Function: This feature changes selected non-lining figures to lining figures.
>Example: The user invokes this feature in order to get lining figures,
>which fit better with all-capital text. Various characters designed to
>be used with figures may also be covered by this feature. In cases
>where lining figures are the default form, this feature would undo
>previous substitutions.
>Recommended implementation: The lnum table maps each oldstyle figure,
>and any associated characters to the corresponding lining form (GSUB
>lookup type 1). If the default figures are non-lining, they too are
>mapped to the corresponding lining form.
>Application interface: For GIDs found in the lnum coverage table, the
>application passes a GID to the lnum table and gets back a new GID.
>Even if the current figures resulted from an earlier substitution, it
>may not be correct to simply revert to the original GIDs, because of
>interaction with the figure width features, so it's best to use this
>table.
>UI suggestion: This feature should be inactive by default. Users can
>switch between the default and lining figure sets by turning this
>feature on or off. Note that this feature is distinct from the figure
>width features (pnum and tnum). When the user invokes this feature,
>the application may wish to inquire whether a change in width is also
>desired.
>
>ONUM
>
>Function: This feature changes selected figures from the default or
>lining style to oldstyle form.
>Example: The user invokes this feature to get oldstyle figures, which
>fit better into the flow of normal upper- and lowercase text. Various
>characters designed to be used with figures may also have oldstyle
>versions.
>Recommended implementation: The onum table maps each lining figure,
>and any associated characters, to the corresponding oldstyle form
>(GSUB lookup type 1). If the default figures are non-lining, they too
>are mapped to the corresponding oldstyle form.
>Application interface: For GIDs found in the onum coverage table, the
>application passes a GID to the onum table and gets back a new GID.
>UI suggestion: Users can switch between the default and oldstyle
>figure sets by turning this feature on or off. Note: This feature is
>separate from the figure-width features pnum and tnum. When the user
>changes figure style, the application may want to query whether a
>change in width is also desired.
>
>
>------------------------------------
>
>Yahoo! Groups Links
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20100329/00ef0e6b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/x-ygp-stripped
Size: 300 bytes
Desc: ~WRD000.jpg
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20100329/00ef0e6b/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/x-ygp-stripped
Size: 322 bytes
Desc: image001.jpg
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20100329/00ef0e6b/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/x-ygp-stripped
Size: 322 bytes
Desc: image002.jpg
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20100329/00ef0e6b/attachment-0002.bin>
More information about the mpeg-otspec
mailing list