[Unicode]   Common Locale Data Repository : Bug Tracking Home | Site Map | Search
 
Modify

CLDR Ticket #11267(new data: out-of-scope)

Opened 5 weeks ago

Last modified 12 days ago

Typography section not so typographic

Reported by: kent.karlsson14@… Owned by: anybody
Component: unknown Data Locale:
Phase: dsub Review:
Weeks: Data Xpath:
Xref:

Description

Very many of the translations given in the "typography" section, and even the English model strings there, are in error, often gravely so, sometimes bordering on being comical. And yes, several of the strings given in English are outright wrong, or at least unclear and misleading. The translations are often either direct translations of the given string (leading to something that is often directly wrong), or not using the normal typographic terminology. They also have the same lack of being systematic as the English model.

First of all, the "model" (the English language strings) are unsystematic (e.g. changing base term at the extremes of a scale, where the terminology is not well established anyway, and there would be no problem in being systematic, quite the contrary) and have alternatives in all the wrong places, but not in places where it would make some sense. And CLDR tries to force this upon all other languages.

Secondly, many of the given English terms are too terse, and in some cases also wrong. This leads to that many translations are wrong, often much more so than the English model string, or uses improper terminology.

I have reviewed this issue for the following languages: English, Swedish, Norwegian, Danish, Icelandic, German, Dutch and French. (PDF files attached.) They may be subject to spell corrections or inflection changes. I have also included Finnish, Italian, Spanish and Portuguese, but these are more tentative.

However, all, I mean ALL, other languages in CLDR have similar problems in this area.

Attachments

en.pdf (577.2 KB) - added by kent.karlsson14@… 5 weeks ago.
sv.pdf (345.3 KB) - added by kent.karlsson14@… 5 weeks ago.
da.pdf (351.7 KB) - added by kent.karlsson14@… 5 weeks ago.
nb.pdf (271.9 KB) - added by kent.karlsson14@… 5 weeks ago.
is.pdf (341.9 KB) - added by kent.karlsson14@… 5 weeks ago.
de.pdf (268.4 KB) - added by kent.karlsson14@… 5 weeks ago.
nl.pdf (303.7 KB) - added by kent.karlsson14@… 5 weeks ago.
fr.pdf (272.6 KB) - added by kent.karlsson14@… 5 weeks ago.
it.pdf (327.0 KB) - added by kent.karlsson14@… 5 weeks ago.
pt.pdf (303.6 KB) - added by kent.karlsson14@… 5 weeks ago.
es.pdf (295.8 KB) - added by kent.karlsson14@… 5 weeks ago.
fi.pdf (266.2 KB) - added by kent.karlsson14@… 5 weeks ago.

Change History

Changed 5 weeks ago by kent.karlsson14@…

Changed 5 weeks ago by kent.karlsson14@…

Changed 5 weeks ago by kent.karlsson14@…

Changed 5 weeks ago by kent.karlsson14@…

Changed 5 weeks ago by kent.karlsson14@…

Changed 5 weeks ago by kent.karlsson14@…

Changed 5 weeks ago by kent.karlsson14@…

Changed 5 weeks ago by kent.karlsson14@…

Changed 5 weeks ago by kent.karlsson14@…

Changed 5 weeks ago by kent.karlsson14@…

Changed 5 weeks ago by kent.karlsson14@…

Changed 5 weeks ago by kent.karlsson14@…

comment:1 Changed 5 weeks ago by mark

  • Status changed from new to closed
  • Resolution set to out-of-scope

Kent, it is almost never useful to hand off a number of PDFs or xml files with changes.

This was based on data used in OpenType, and names currently in fonts from Adobe, etc. If you disagree as to the English, you can submit a ticket for that.

comment:2 Changed 5 weeks ago by srl

  • Status changed from closed to new

Kent, as Mark said it would be better to include the English content in plain text here rather than marked up PDFs. Can you add a comment here summarizing the English changes?

Information hub should probably link to https://docs.microsoft.com/en-us/typography/opentype/spec/featurelist

there may be some content here that can be added to the sidebar.

and according to https://docs.microsoft.com/en-us/typography/opentype/spec/dvaraxisreg it does seem that ital-0 is missing in CLDR.

comment:3 Changed 5 weeks ago by srl

Kent, you say that some terms are not "normal typographic terminology", however they are actually found in the OpenType spec. As the sidebar says, these are not general purpose typographical terminology, but specifically, translations of specific OpenType terms. As such, for example https://docs.microsoft.com/en-us/typography/opentype/spec/dvaraxistag_wdth explicitly mentions "extended" which you propose to delete as "term does not seem to be used in this sense (for typography)."

comment:4 Changed 4 weeks ago by kent.karlsson14@…

This is a bit long. But there are so many problems.

Zerothly, this ticket is far from being out-of-scope!

Firstly, translators apparently do not understand that there are "axes" with "named values along each axis". In addition, the values are named in an unclear manner (in the English currently given in ST). Therefore the translations are often completely off-the-wall, making no sense at all.

Furthermore, the authors of the Opentype spec did not get everything right. Concerning terminology that is now to be translated via CLDR, there are a number of issues. I give details below.


Features:

afrc::
vertical fractions -> "fraction sequences as vertical fractions"
This one does not affect the display of "VULGAR FRACTION" characters, which one might think given the original short description. Better description, reflecting what this feature really does: "fraction sequences as vertical fractions". (Actually, this is a little bit of poor mans math layout; otherwise consider using MathML or similar, if possible.)

cpsp::
capital spacing -> "extra spacing between capital letters"
What? Capitals are spaced... Or is this some "knob that can be turned"? No! What this feature really does is: (predetermined) "extra spacing between capital letters", if the font at all supports this ill-conceived feature. This is a bad idea, this feature should not be supported, neither in fonts nor in CLDR.

Furthermore: It is not clear if it applies also to small caps, especially if the small caps are generated from lowercase letters (smcp instead of c2sc). So apart from generally being a bad idea, it is also not well specified.

dlig::
optional ligatures -> "extra ligatures"
This enables "extra ligatures", if the font has any. That is a better description.

frac::
diagonal fractions -> "fraction sequences as diagonal fractions"
This one does not affect the display of "VULGAR FRACTION" characters, which one might think given the original short description. Better description, reflecting what this feature really does: "fraction sequences as diagonal fractions". (Actually, this is a little bit of poor mans math layout; otherwise consider using MathML or similar, if possible.)

lnum::
lining numbers -> "uppercase digits"
This is primarily called (what corresponds to) "uppercase digits" in many languages. (And "digits" rather than "numbers".) 'lining' is sometimes grossly, and comically, misinterpreted. "uppercase digits" is a good description in English as well, and helps translators pick the best translation.

onum::
old-style figures -> "lowercase digits"
This is primarily called (what corresponds to) "lowercase digits" in many languages. They are not really "old-style", it is a common modern style recommended for running text. (Sometimes called small cap digits, but that is technically wrong, and must not be allowed as name for this one.) "lowercase digits" is a good description in English as well, and helps translators pick the best translation.

ordn::
ordinals -> "raised lowercase letters"
This feature is not at all related to ordinals as such. What this feature really does is: "raised lowercase letters". Can be used for things like French 'Mme', and other abbreviations (sometimes, in some languages, for ordinal abbreviations too).

However, this is just as bad as using <sup> (in HTML) for this effect: it is very unlikely to survive cut-and-paste. Much better to use Unicode's superscript letters (I know that the UTC, mistakenly, does not like that.)

c2sc::
uppercase as small caps (missing in CLDR, please add)
This one has for unknown reasons been skipped (so far) in CLDR.

Using c2sc is a GOOD idea, for all-caps abbreviations. In addition, c2sp should also make (uppercase) digits display in small cap style; but that is unfortunately not (yet) specified in Opentype.

smcp::
small capitals -> "lowercase as small capitals"
Incomplete description. It should be "lowercase as small capitals". That is what the smcp feature really does.

Using smcp is a BAD idea, though seen as style sometimes. It confuses uppercase and lowercase. (Granted, there are small cap letters encoded in Unicode, but that is only for phonetic notation, so does not affect this judgements about c2cs and smcp.)

pnum::
proportional numbers -> "variable width digits"
Well, it is sometimes called that; but that is a strange term. Proportional to what?? It does not make any sense. In addition, it's digits, not numbers, indeed it is only 0-9, not other digits. "variable width digits" is a clearer, and sensible, description.

tnum::
tabular numbers -> "fixed-width digits"
That description is too open to misinterpretation (and mistranslation, sometimes comically so). And it is digits, not numbers. "fixed-width digits".

zero::
slashed zero -> "marked 0" (or "marked zero")
The term should be a bit more general. Yes, "slashing" is one way of doing this. But in the terminals days, often the zero was marked with a dot in the middle. In addition slashing makes the zero look like a Danish Ø, so not helpful. Some even misinterprets this as the empty set symbol. Use the more general description "marked 0".

===========

Axes:

You need to clarify that these are axes, and for each axis there are named value points. It is very apparent that translators do not get this at all.

It is questionable to give specific names to points on a numerical axis where the number scale is not arbitrary, e.g. a size, an angular degree or a percentage. Some names should apply to ranges rather than (default) points on the axis, which I have pointed out before.

Here (as you should in ST) I group the axis name with the axis value names for that axis.


axis:

ital::
italic -> "style type"
This is supposed to be the AXIS name for italic vs non-italic (i.e. regular/normal). "style type" would be a better name for this axis.

axis values:

ital-0 (missing in CLDR, please add)::
roman
Somehow you have left out "ital-0" which is normal/regular/roman. You have included the "normal" case for other axes, why it is omitted for this one beats me.

ital-1::
cursive -> "italic"
This is one of the values for the "ital" axis. It is supposed to say "italic" (in English). "cursive" means "connected script" in English (while it does mean "italic" in some other languages), and has been erroneously translated as such.


axis:

opsz::
optical size -> "optical adaptation"
This is not a size (axis); it is supposed to the name of the AXIS for the optical adaptation (to some size). "optical adaptation" is a be better name for this axis.

axis values:

I don't think naming a few values on this axis to be particularly useful (for a font user). So I would actually suggest not including any of the point values you have. (If you would name the corresponding point sizes (correspondingly) as well, then maybe... But I bet you don't want to do that!)

And most of the names are COMPLETELY misinterpreted by many or even all translators.

It is sometimes useful to use an explicit value which does not coincide with the point size. But no need to fixate at all on the five points you have selected. So, again, I would actually suggest not to include any of the point values you have; they don't need any particular names.

The MOST useful case for this is AUTO, which is what CSS allows for:

font-optical-sizing: auto;

opsz-auto ADD::
optically adapt for the given size

opsz-X ADD::
optically adapt for size: {0} pt

opsz-8 DOUBTFUL, SHOULD PROBABLY DELETE::
caption -> "image text"
Many translators misread that as "heading". "image text" is a clearer description (and corresponds to what many languages use).

opsz-12 DOUBTFUL, SHOULD PROBABLY DELETE::
text -> "running text" or "main text"
All of the "opsz-X" refer to some kind of text. For "opsz-12" it is "running text" or "main text". This has a name in several languages, e.g. "brödtext" in Swedish.

opsz-18 DOUBTFUL, SHOULD PROBABLY DELETE::
titling -> "title text" or "heading text"
Horribly mistranslated sometimes (see Italian). "title text" or "heading text".

opsz-72 DOUBTFUL, SHOULD PROBABLY DELETE::
display -> "signage text"
Horribly misread by just about every translator as "screen" or "show". Call it "signage text".

opsz-144 DOUBTFUL, SHOULD PROBABLY DELETE::
poster -> "poster text"


axis:

slnt::
slant
Or "obliqueness". Here it may be sensible to have variant names; but that may also be a problem for some languages which have not imported the word "oblique" somehow (and many might not have). A problem for the values along this axis in some locales (in current ST values), is that they haven't always used the same base word in the same inflection for the non-upright cases; the really should do that.

axis values:

You seem to have gotten the angles wrong in CLDR for this. The angle values go counter-clockwise, i.e. −12 (degrees) is slanted, and +12 (degrees) is backslanted.

For a font user, it might sometimes be useful to be able to give the slant more generally as a degree and be able to present that back to the user, like "slant: {0}°", in addition to the named points on the scale.

Note that the CSS font-style property oblique will default to a (negative!) 20 degree slant!

slnt-X ADD::
slant: {0}°

slnt--12 should be slnt-12 (i.e. slant(ed) by +12 degrees, which is a "back" slant!!)::
backslanted or "reverse oblique"

slnt-0::
upright "nonslanted" or (better, but long) "no extra slant"
or "regular" or "normal"

It may seem that this is an easy one. I think maybe not. Italic fonts are slanted, not upright, but will still have slnt-0, IIUC. Then "upright" is misleading. "unslanted" or "nonslanted" (i.e. no extra slant in addition to any designed-in slant, esp. for italic fonts).

slnt-12 should be slnt--12 (i.e. slant(ed) by −12 degrees, which is a forward slant)::
slanted or "oblique"

slnt-24 should be slnt--24 (i.e. slant(ed) by −24 degrees)::
extra-slanted or "extra-oblique"


axis:

wdth::
width "width/height" or better(!) "horizontal font scaling"
It not a really a width, but rather an "overall width to height ratio", and then a judgement as to what kind of text that is suitable for. That is far to clumsy, but "wideness" might work (and some languages have several words for width (e.g. 'broadness'), and that might work, but is not fully clear. I think the best name for this is "horizontal scaling". But it is not plain horizontal scaling, but scaling with optical adjustment for the horizontal scaling.

axis values:

Here you have gone overboard with alternative names for the axis values, a full three alternatives for each of the axis points named.

That is way too much.

Firstly, the compressed/extended values are not used for this as a typographic term (no matter what the Opentype specification says). Well, "compressed" is used (w.r.t. digital fonts), but then in the sense of zip/gzip/your-favourite-compression-scheme compression, not as a typographic term.

Secondly, while narrow/wide is sometimes used as a layman term for this, the proper typographic name is condensed/expanded. Having two alternatives may be ok for some languages, it may also pose problems for many languages. So stick with only the proper name for now, maybe add the layman terms for some languages if needed later (much later).

  • ultracondensed
  • extra-condensed
  • condensed
  • semicondensed
  • normal width
  • semiexpanded
  • expanded
  • extra-expanded
  • ultraexpanded

For a font user, it is still useful to be able to give the condensation/expansion more generally as a percentage and also be able to present that back to the user, like "horizontal font scaling: {0} %", in addition to the named points on the scale. (Including the word "font" there to indicate that it is not raw scaling (which CSS also allows), which can have a slightly different effect [e.g. raw scaling would scale serifs, but horizontal font scaling should not, strokes may be scaled differently as well].)

wdth-X ADD::
horizontal font scaling: {0} %

wdth-50::
ultracondensed

wdth-50-compressed DELETE::
ultracompressed
While it seems logical, this term does not seem to be used in this sense (for typography). "Compressed" is used for zip-compression and similar.

wdth-50-narrow NOT FOR NOW::
ultranarrow
Layman's term, not needed for anyone that knows even a little bit of typography:

wdth-62.5::
extra-condensed

wdth-62.5-compressed DELETE::
extra-compressed
While it seems logical, this term does not seem to be used in this sense (for typography).

wdth-62.5-narrow NOT FOR NOW::
extra-narrow

wdth-75::
condensed

wdth-75-compressed DELETE::
compressed
While it seems logical, this term does not seem to be used in this sense (for typography).

wdth-75-narrow NOT FOR NOW::
compressed -> "narrow"
I guess this one is supposed to say "narrow".

wdth-87.5::
semicondensed

wdth-87.5-compressed DELETE::
semicompressed
While it seems logical, this term does not seem to be used in this sense (for typography).

wdth-87.5-narrow NOT FOR NOW::
seminarrow

wdth-100::
normal -> "normal width"
Indicate the axis somehow. "normal width" or "ordinary width" (or use "regular" instead of "normal")

wdth-112.5::
semiexpanded

wdth-112.5-extended DELETE::
semiextended
While it seems logical, this term does not seem to be used in this sense (for typography).

wdth-112.5-wide NOT FOR NOW::
semiwide

wdth-125::
expanded

wdth-125-extended DELETE::
extended
While it seems logical, this term does not seem to be used in this sense (for typography).

wdth-125-wide NOT FOR NOW::
wide

wdth-150::
extra-expanded

wdth-150-extended DELETE::
extra-extended
While it seems logical, this term does not seem to be used in this sense (for typography).

wdth-150-wide NOT FOR NOW::
extra-wide

wdth-200::
ultraexpanded

wdth-200-extended DELETE::
ultraextended
While it seems logical, this term does not seem to be used in this sense (for typography).

wdth-200-wide NOT FOR NOW::
ultrawide


axis:

wght::
weight -> "stroke width" or (better) "stroke thickness"
Maybe ok in English, but may lead translators astray. It is not referred to as "weight" in other languages, despite using words corresponding to "fat"/"lean" for the values along this axis. "stroke width" or "stroke thickness" (not as a measurement, but as a judgement) is more accurate.

axis values:

For these axis values, you seem to have been taken in the result of some very ill-willing committee. It is not that hard to find a consistent value scale scheme, but some(?) ill-willing committee messed it all up.

Here the variants and axis extremes have become hypermessedup, and needs to be thoroughly cleaned up. The current mess helps absolutely no-one.

In addition some of the (messed up) values are extra unhelpful for some languages, where "bold" is referred to (what corresponds to) "black"/"blackish". (I think that may be layman terms rather than professional terms, but that is different issue.) Note that "black" has been inconsistently used in the scale names in English as given in ST so far. Which wreaks havoc in the translations.

I don't know the reason for this mess-up. Maybe it is just that a small number of typographers cannot agree. In any case, there is no reason for foisting this horrible and unhelpful mess upon the world. Granted, the terminology for the "extremes" of the half-axes here. Still not a reason for trying to foist this mess upon the world, and there is nothing forgiving about this mess.

Many languages uses terms corresponding to "lean/fat" for describing points on this axis. For English, and English only, "bold" is used instead of "fat". Some languages use words corresponding to "black" or "blackish" for the "bold" side of this axis, but that may be layman terms rather than professional terms. It is not clear if "lean" or "light" is the most appropriate base name for the other half-axis for English, and English only. For other languages than English, a word corresponding to "lean" should (and is) used. But going from "light" in English most translators will mistranslate, as seen in current ST data.

  • ultralean
  • extra-lean
  • lean
  • semilean
  • quarterlean
  • normal thickness
  • quarterbold
  • semibold
  • bold
  • extra-bold
  • ultrabold
  • hyperbold

Unfortunately the numeric values on this axis are not interpretable as a sizes nor as percentages (really, though could be, to some extent). But for a font user, it is still useful to be able to give the thickness more generally as a number and also be able to present that back to the user, like "stroke thickness: {0}", in addition to the named points on the scale. Compare CSS:

    font-weight: 550;

wght-X ADD::
stroke thickness: {0}

wght-100::
thin -> "ultralight" or "ultralean"
No need to confuse matters by introducing yet another term ("thin"). Granted that the terminology for these extreme cases aren't well established. Still no need to confuse matters by introducing yet another term. "ultralight" or "ultralean".

wght-200::
extra-light or "extra-lean"

wght-200-ultra DELETE!!!::
ultralight
This should be used for wght-100.

wght-300::
light or "lean"
In other languages, one uses a term corresponding to "lean" (for the full series of the "anti-bold" semi-axis). So this term should not be translated directly to other languages. And... It seems it is called lean also in English...

wght-350::
semilight or "semilean"

wght-380::
book -> "quarterlight" or "quarterlean"
No need to confuse matters by introducing yet another term ("book"). And there is nothing saying that this thickness is particularly suited for books... (that would depend on the individual font). "quarterlight"

wght-400::
regular -> "normal weight"
Indicate the axis somehow. "normal weight" or "ordinary weight" (or use "thickness" instead of "weight"; or use "regular" instead of "normal" while still indicating the axis).

wght-500::
medium -> "quarterbold"
No need to confuse matters by introducing yet another term. And medium of what? If anything, regular and medium should be equivalent. "quarterbold"

wght-600::
semibold
("semi"/"demi" means "half") It is actually more like three-quarter-bold (or, to be really nit-picking, two-thirds-bold). But such nit-picking is probably not useful.

wght-600-demi DELETE::
demibold
This is a needless variant, even for English.

wght-700::
bold

wght-800::
extra-bold

wght-900::
black -> "ultrabold"
No need to confuse matters by introducing yet another term. Granted that the terminology for these extreme cases aren't well established. Still no need to confuse matters by introducing yet another term, especially when it causes problems for translations. "ultrabold"

wght-900-heavy DELETE::
heavy
No need to confuse matters by introducing yet another term. Granted that the terminology for these extreme cases aren't well established. Still no need to confuse matters by introducing yet another term, especially when it causes problems for translations.

wght-950::
extra-black -> "hyperbold"
As above. "hyperbold"

wght-950-ultrablack DELETE::
ultrablack
As above. And... This is a needless variant, even for English, especially when it causes problems for translations.

wght-950-ultraheavy DELETE::
ultraheavy
As above. And... This is a needless variant, even for English, especially when it causes problems for translations.


comment:5 Changed 4 weeks ago by kent.karlsson14@…

There is no chance whatsoever of fixing all these problem for this round of ST/CLDR. This is a clear case of back to the drawing board, and make a new try, after fixing all the problems, for a later version.

The current data in ST for the "typography" section is completely unusable, due to both very bad translations as well as the basic problems detailed above. That data cannot be used, nor is there a quick fix. DELETE ALL OF IT, FOR THIS ROUND.

comment:6 Changed 12 days ago by kent.karlsson14@…

Rereviewing the descriptions (in English) for the typographic part, I find the following descriptions to be best. (Given as an XML snippet, which is the most direct way to present this.)

	<!-- en.xml -->
	<typographicNames>


		<featureName type="afrc">fraction sequences as vertical fractions</featureName>
		<featureName type="frac">fraction sequences as diagonal fractions</featureName>
		<featureName type="cpsp">extra spacing between capital letters</featureName><!-- should not be used... -->
		<featureName type="dlig">extra ligatures</featureName>
		<featureName type="lnum">uppercase digits</featureName>
		<featureName type="onum">lowercase digits</featureName>
		<featureName type="ordn">raised lowercase letters</featureName><!-- used for various abbreviations, not just abbreviated ordinals; but better to use Unicode superscript letters -->
		<featureName type="smcp">lowercase as small capitals</featureName><!-- should not be used... (but is...) -->
		<featureName type="c2sc">uppercase as small capitals</featureName><!-- used for all-cap abbreviations; should(!) also affect uppercase digits to be small capital digits -->
		<featureName type="pnum">variable width digits</featureName>
		<featureName type="tnum">fixed-width digits</featureName>
		<featureName type="zero">marked zero</featureName>



		<!-- This axis is necessarily discrete, as opposed to all the other axes here -->
		<!-- which can be continuous (even though only discrete points can be named). -->
		<axisName type="ital">style type</axisName>
		<styleName type="ital" subtype="0">roman</styleName><!-- i.e. not italic (so far). -->
		<styleName type="ital" subtype="1">italic</styleName><!-- called "cursive" in several languages, though NOT in English nor Spanish. -->
		<!-- One could imagine other reasonable values (2, 3, ...) here, such as for "fraktur" or "handwriting", -->
		<!-- but such are not (yet) specified in Opentype. -->


		<axisName type="opsz">optical adaptation</axisName>
		<styleName type="opsz" subtype="auto">adapt for actual text size</styleName>
		<styleName type="opsz" subtype="X">adapt for size: {0} pt</styleName><!-- the "{0}" part should, in use, be formatted according to locale, e.g. "10,5" or "10.5" -->
		<!-- probably delete these named size adaptations; does not appear very useful to name these. -->
		<!--styleName type="opsz" subtype="8">adapt for image (caption) text size</styleName-->
		<!--styleName type="opsz" subtype="12">adapt for running text size</styleName-->
		<!--styleName type="opsz" subtype="18">adapt for title text size</styleName-->
		<!--styleName type="opsz" subtype="72">adapt for signage text size</styleName--><!-- using "display" will inevitably be mistranslated -->
		<!--styleName type="opsz" subtype="144">adapt for poster text size</styleName-->


		<!-- For this axis, and this axis only, it may be sensible to have an alternative description (available for several languages). -->
		<!-- Note that a negative value signifies a forward slant, while positive is a backwards slant. -->
		<axisName type="slnt">slant</axisName><!-- obliqueness -->
		<styleName type="slnt" subtype="X">slant: {0}°</styleName><!-- obliqueness: {0}° -->
		<styleName type="slnt" subtype="0">upright</styleName><!-- unslanted, non-oblique -->
		<styleName type="slnt" subtype="-12">slanted</styleName><!-- oblique -->
		<styleName type="slnt" subtype="-20">CSS default slanted</styleName><!-- CSS default oblique -->
		<styleName type="slnt" subtype="-24">extra-slanted</styleName><!-- extra-oblique -->
		<styleName type="slnt" subtype="12">backslanted</styleName><!-- reverse oblique -->


		<!-- Narrow/wide is a possible alternative naming scheme, but that can wait to a later version, or indefinetely. -->
		<axisName type="wdth">horizontal font scaling</axisName><!-- including optical adaptation, as opposed to crude scaling -->
		<styleName type="wdth" subtype="X">horizontal font scaling: {0} %</styleName>
		<styleName type="wdth" subtype="50">ultracondensed</styleName>
		<styleName type="wdth" subtype="62.5">extra-condensed</styleName>
		<styleName type="wdth" subtype="75">condensed</styleName>
		<styleName type="wdth" subtype="87.5">semicondensed</styleName>
		<styleName type="wdth" subtype="100">normal width</styleName>
		<styleName type="wdth" subtype="112.5">semiexpanded</styleName>
		<styleName type="wdth" subtype="125">expanded</styleName>
		<styleName type="wdth" subtype="150">extra-expanded</styleName>
		<styleName type="wdth" subtype="200">ultraexpanded</styleName>


		<!-- For English, and English only(!), "light" can be an alternative to "lean" here. -->
		<axisName type="wght">stroke thickness</axisName>
		<styleName type="wght" subtype="X">stroke thickness: {0}</styleName><!-- "kind of" percent of ultralean; so maybe use " {0} %", but it is only "kind of" -->
		<!--styleName type="wght" subtype="70">hyperlean</styleName-->
		<styleName type="wght" subtype="100">ultralean</styleName>
		<styleName type="wght" subtype="200">extra-lean</styleName>
		<styleName type="wght" subtype="300">lean</styleName>
		<styleName type="wght" subtype="350">semilean</styleName>
		<styleName type="wght" subtype="380">quarterlean</styleName>
		<styleName type="wght" subtype="400">normal thickness</styleName>
		<styleName type="wght" subtype="500">quarter bold</styleName>
		<styleName type="wght" subtype="600">semibold</styleName>
		<styleName type="wght" subtype="700">bold</styleName>
		<styleName type="wght" subtype="800">extra-bold</styleName>
		<styleName type="wght" subtype="900">ultrabold</styleName>
		<styleName type="wght" subtype="950">hyperbold</styleName>


	</typographicNames>
View

Add a comment

Modify Ticket

Action
as new
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.