a bit like
Really?
70 Matching Annotations
- Jul 2020
-
commontype-standard.github.io commontype-standard.github.io
-
-
The segments are sorted in order of increasing endCode values
Move to after table 5.7
-
The segment values are specified in four parallel arrays. Each segment is described by a startCode and endCode, along with an idDelta and an idRangeOffset, which are used for mapping the character codes in the segment.
Remove this.
-
which includes parameters for an optimized search of the segment list
No it doesn't.
-
module
modulo
-
Unicode font for Windows
Only true for BMP
-
-
commontype-standard.github.io commontype-standard.github.io
-
This means that it can be used for encodings in the cmap table but not for strings in the name table
This is a problem!
-
-
commontype-standard.github.io commontype-standard.github.io
-
Number of Storage Area locations.
All of these need more context. I presume it's a postscript thing, but it's not clear.
-
instructions do not use the twilight zone (Z0)
Really not clear this point what that means.
-
Fixed
Version
-
(Note the difference in the representation of a non-zero fractional part, in Fixed numbers.)
Change type to Version and remove this.
-
Both formats of CommonType require a maxp table because a number of applications call the Windows GetFontData( ) API on the maxp table to determine the number of glyphs in the font.
Let's just say it's required by the standard, not because of some implementation detail.
-
-
commontype-standard.github.io commontype-standard.github.io
-
phantom points
Not defined at this point.
-
rsb is calculated as follows
Not really relevant to this table.
-
The type longHorMetric
This isn't the right thing to start the chapter with.
-
-
commontype-standard.github.io commontype-standard.github.io
-
0 for current format.
What?
-
-
commontype-standard.github.io commontype-standard.github.io
-
SubRule
Everything else is Subst - ContextSubstFormat1, SubstLookupRecord, SubstCount, etc. This is Sub. It should be SubstRule, SubstRuleSet and likewise ChainSubstRule etc.
-
Contextual Substitution Subtable
The naming here is an issue. Both GSUB5 and GSUB6 lookups chain, it's just that GSUB6 lookups support more context...
-
- Jun 2020
-
commontype-standard.github.io commontype-standard.github.io
-
less than 0.5 or higher
less than 0.5
-
-
commontype-standard.github.io commontype-standard.github.io
-
Table 6.1.Â
In general, having these tables with half a sentence of "description" for each field just isn't enough for a formal specification. Spell everything out.
-
1 for vertical.
Any other values? Italic fonts tend to have this as upem.
-
The amount by which a slanted highlight on a glyph needs to be shifted to produce the best appearance
in font units?
-
-
commontype-standard.github.io commontype-standard.github.io
-
size
...of what?
-
macStyle
More explanation needed here.
-
It seems that Table version number is set to 'OTTO' for CFF based fonts
Not so.
-
should
must?
-
instructions
What instructions?
-
font converted
What?
-
0 for current format.
What?
-
Bit 0: baseline for font at y=0;Bit 1: left sidebearing at x=0;
These need more explanation.
-
However, they are not implemented in CommonType.
Oh for the love of...
-
Agfa MicroType Express engine
I don't think this is a thing any more.
-
Description
Most of these aren't descriptions. They're just notes. Make them descriptions instead and add notes later.
-
The bounding box values
Move this down to later in the document. Too early to talk about this now.
-
-
commontype-standard.github.io commontype-standard.github.io
-
is the glyph to use for that sequence
How do we know what glyph to use for a sequence of Unicode codepoints? We look them up in the cmap table. Surely this is a circular argument.
-
be deprecated
You can't "deprecate" OpenType things, only "discourage" them. Sigh.
-
A few notes here
Drop.
-
If a font contains characters from the Unicode Surrogates Area (U+D800-U+DFFF), which are UCS-4 characters; it's likely that it will also include other, regular 16-bit Unicodes as well. We therefore need a format to map a mixture of 16-bit and 32-bit character codes,
Wait a moment, this is all wrong. Unicode codepoints don't have an inherit bit length.
-
Supporting 4-byte character codesSpecificationWhile the four existing cmap subtable formats which currently exist have served us well, the introduction of the Surrogates Area in Unicode 2.0 has stressed them past the point of utility. This section specifies three formats, format 8, 10 and 12; which directly support 4-byte character codes. A major change introduced with these three formats is a more pure 32-bit orientation. The cmap table version number will continue to be 0x0000, for those fonts that make use of these formats.
Drop this whole section as non-spec-like language.
-
This format is very similar to format 0, in that there is an explicit list of glyph indices for a contiguous range of character code.
If this is genuinely a superset of format 0, then let's deprecate format 0.
-
Trimmed table
I'm not sure why it has this name.
-
This is
Drop
-
obscure indexing trick
Seriously, what?
-
You search for the first endCode that is greater than or equal to the character code you want to map.
Spec-like language.
-
Microsoft standard
No, this isn't!
-
The offset of the byte within this subrange is then used as index into a corresponding subarray of glyphIndexArray. This subarray is also of length entryCount. The value of the idRangeOffset is the number of bytes past the actual location of the idRangeOffset word where the glyphIndexArray element corresponding to firstCode appears.
I'm lost. I'm completely lost. I'm sure there must be a better way of wording this.
-
subrange stays within the 0-255
Doesn't this mean that only one low byte is valid?
-
depends heavily
This is weird language.
-
subArray
There is no subArray in the below.
-
Non-Windows ANSI Type 1 fonts, such as Cyrillic and Central European fonts, that Adobe shipped in the past had "0" (Windows ANSI) recorded in the CharSet field of the .PFM file; ATM for Windows 9x ignores the CharSet altogether. Adobe provides this compatibility cmap encoding in every OTF converted from a Type1 font in which the Encoding is not StandardEncoding.
Historical garbage should be removed.
-
The descriptions of the fields of this table do not include names for them, as most other tables do. The recommendation is to include them: version, numTables, platformID, encodingID, offset.
This has been done.
-
In the fifth paragraph, "UCS-4 (surrogate) characters" should be replaced by "Unicode supplemental characters" or "Unicode supplemental (non-BMP) characters". BMP characters are also UCS-4 characters. And anyways, UCS-4 is an encoding, not a character collection.
This appears to have been done
-
some other encodings that appear in current fonts
This is not how you write a spec.
-
Microsoft Unicode encodings (Platform ID = 3, Encoding ID = 1) must provide
This sentence is stupid. Encodings don't provide subtables, fonts do.
-
The platform ID and platform-specific encoding ID in the header entry
Deprecate this completely in CT1.9. Consumers should accept it but producers should only produce Unicode encoded fonts.
-
This field must be set to zero for all cmap subtables whose platform IDs are other than Macintosh (platform ID 1). For cmap subtables whose platform IDs are Macintosh, set this field to the Macintosh language ID of the cmap subtable plus one, or to zero if the cmap subtable is not language-specific. For example, a Mac OS Turkish cmap subtable must set this field to 18, since the Macintosh language ID for Turkish is 17. A Mac OS Roman cmap subtable must set this field to 0, since Mac OS Roman is not a language-specific encoding.
This whole thing would be greatly simplified just by writing out the valid combinations. Macintosh font? These are the values you need. Windows font? Choose from one of these.
-
-
commontype-standard.github.io commontype-standard.github.io
-
This document
This document is the one you're currently reading.
-
operating systems and browsing applications
font consumers
-
typographic glyph variants
Unicode generally isn't used for typographic glyph variants.
-
whether the fonts contain TrueType outlines or CFF (PostScript) outlines.
Or indeed anything else.
-
Related documentation
Need a "Definitions" section in here, which covers things like "font file", "client" (which should be split into "font producer" and "font consumer"/"shaper"/"layout application"/something like that)
-
But the user model is the same: CommonType fonts just work.
Redundant and sounds more sales-y than spec-y.
-
better protection
This is not explained. I'm guessing it refers to DSIG, but...?
-
TrueType Open v.2.0
I have never heard anyone call it that. Maybe this was true for a little while many years ago?
-
-
commontype-standard.github.io commontype-standard.github.io
-
PostScript font extensions
They're not extensions now, they're part of the real thing.
-
function correctly
Wooly.
-
TrueType or PostScript outlines
Or indeed any other kind of representation format
-
Multiple Master support in CommonType, has been discontinued as of version 1.3 of the specification. The 'fvar', 'MMSD', 'MMFX' tables have hence been removed.
Remove, replace with variation font tables.
-
used
Used? Required? Typically contain?
-
-
commontype-standard.github.io commontype-standard.github.io
-
create an annotation
This is an example of an annotation.
-