Text Proposal Feedback

[macnmm]

I have some thoughts coming from the perspective of having implemented text layout engines outside of the web context, and as such often find key differences in how CSS and HTML define text layout parameters versus outside the web, that could be applicable here.

But first, a question: Is it a requirement for this proposal to assume nothing about the rendering environment, such as if specific fonts are resident, the screen resolution, whether different implementations support specific text features, etc? One key difference to me about a CSS-like approach versus one more direct and specific to the rendering intent is how exactly can one specify the output and with what degree of accuracy is it required?

An example of this would be Weight of 100-900. This value for font weight, in practice, is not reliable in choosing the correct font face (style, if you prefer) across all fonts and writing scripts, and so using it in CSS results in not very predictable or reliable output. It is a very rough suggestion to the User Agent, in other words, but for the Web, this indirection is a feature. For print output, or graphic design-oriented content, it works less well. Can one assume the same indirection is needed for USD? Or can we just, for example, require a resident font be specified and be done with it?

"typeface". I would prefer "font" or "fontname" or even "psname" here, because in type design, the "typeface" refers to a family of related fonts, and in digital fonts to get to a specific weight, width and style within a font family you need to refer to the font's name properly. This parameter appears to refer to a specific font in that way.

"Bold" "Italic". Because font fauxing (digitally manipulating the render and spacing of a font's glyphs) is a feature that, while it worked when there were few fonts available and those fonts were lo-res bitmaps, it is really bad to use today as, for example, Japanese fonts do not do well when faux italic or bold is used with them. If you wish to refer to the Bold or Italic font in a font family with a shortcut, it will not work well if no such fonts exist in the family (again, Japanese fonts lack these altogether, but other scripts' fonts also cannot guarantee all weights have a "Bold" slot, or that there is an "italic" design). I would recommend eliminating these and just use the right font.

"Weight": see above. I recommend using the right font.

"Height": This illustration needs to be more specific as to what font feature it refers to. If optical sizing, perhaps the direct application of 'opsz' OTF feature is sufficient? "Height" is also a term that has many usages in layout, especially when the layout contains complex script text or vertical text, with different ideas of the line "height" and which font metrics should demark its boundaries. I would recommend a different term for glyph changes that depend on size.

"Width Factor": This is a simple x-scale factor, so stroke widths will become uneven, etc., but it nevertheless still is often used in many applications and languages. However, it may be useful to relate this to a variable font width axis, which would give superior typographic results, if that is desirable...

"Oblique": I wonder if this mesh transformation could be combined with "Width Factor" and any other affine matrix transform and just passed as a comprehensive warping mechanism? One thing about "Oblique" is again that it is Latin-specific in its application, and that other transformations are more useful in other scripts. A per-glyph mesh that creates rotated rhombuses in Japanese is called "shatai" for example, and a mesh to transform a word at a time could be used for obliquing...

"Character Spacing": Does the spacing get applied at line ends? What are the units?

"Underline": The line thickness and location can be obtained from the font for Latin and some other scripts, but for CJK must be offset so the glyphs are not stepped on. If there are different underline locations for a line of text, should the line be broken or moved to the lowest point and joined?

"Overline": This is used in CJK, and is the default for vertical text (called "underline" though, going on the right).

"Strikethrough": Again, line location and thickness is obtainable from the font for Latin and must be offset for CJK and some other scripts.

"Color": Is color space and accurate color matching a requirement? Is how the color composites into the scene a consideration?

"Background Color": The line height and highlight of it, which changes script-by-script (e.g. ascent to descent for Latin, ideographic embox for Japanese), should be specified somewhere, and similarly to underline on mixed runs, whether each highlighted run is the height of the run or the max height of the line should be specified.

"Direction": RTL text has both a text run direction (RTL glyph layout), and also a paragraph direction (RTL for Arabic-dominant paragraphs or LTR for Latin-dominant, for example). In vertical text, the text flow (all paragraphs) have a layout direction and line procession (e.g. vertical RTL, vertical LTR) and the glyphs in the line have an orientation (e.g. upright or rotated).

"Line Space": What measurement points are used for this gap depends on the writing script (e.g. Latin uses baseline to baseline for leading and is undefined as far as the line gap but could be descent to ascent. Japanese uses ideographic embox bottom to top). What are the units? Can it be a percentage of the type size? Always absolute units?

"Lines flow direction": see Direction, above. I would relate these together since not all combinations are valid if separated.

"Paragraph Space": same comment as Line Space, above.

"Tab stops": What happens with RTL text as far as the types? Does this imply the presence of a configurable text ruler? Where would the ruler's origin be?

"Paragraph alignment": Do these switch direction in RTL paragraphs? Does Justify and Distributed distribute space in a specific way writing script by writing script? It should. For Arabic, what does it do, for example? Is it out of scope for this document to recommend behaviors or minimum viable results?

"Column": Columns typically are either balanced or uneven, meaning the text flow can change to fill all the columns evenly or not. They have a gap defined. They can have a grid where the line leading will be adjusted so if there is an interruption in the flow the next line will line up its baseline with the baselines in the adjacent columns.

"Column alignment": This and the above look more like table cells or single frames than columns. How is a flow that crosses columns to be aligned vertically? Is it only the last column that isn't full?

"Column margin": This also just looks like a single frame parameter, rather than something to do with columns.

Missing in frames is the first line baseline or first line height—Latin text can use the ascent or the cap height for the first line, CJK can use the ideographic embox top to match the frame top. This will change font by font or script by script, so it is important to specify if you want control and accuracy of text placement.

Properties of TextStyle:

"font:typeface": To reduce confusion/pedantic commentary (see above), perhaps use font:psname which is specific as to what you are referencing and will faithfully resolve to a real font.

"font:format": I would also include font version, if you care about disambiguating between fonts of the same name but different formats.

"font:altTypeface": One choice is not going to be enough for most fallback use cases. I would define a fallback mechanism whereby you could specify a fallback font for a given range of Unicode, and make sure that font was resident if those Unicodes were to be drawn. You would end up with an array of fallback fonts and overlapping ranges and could then prioritize for the best result.

"font:altFormat": same as above

"font:weight": This won't work if you care about fidelity. However if you want a level of indirection so the user can specify a suggestion for matching a weight to the fonts in the system, this is ok for Latin script.

"font:bold,italic: This won't work for high fidelity either -- can you just specify a resident font?

"charHeight": Since the "height" of the text in vertical layout can change based on the glyph orientation in the line, this will be problematic or possibly confusing.