freetype
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Font files and vertical text


From: suzuki toshiya
Subject: Re: Font files and vertical text
Date: Sun, 16 May 2021 21:01:24 +0900
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1

Dear Mr. Hallikainen,

Thank you for the explanation of the technical background of your question.

The point I have to emphasize is: FreeType is a full-featured font driver
of TrueType and some PostScript fonts, but not a full-featured font driver
of ISO/IEC 14496-22 aka OpenType. OpenType is a mixture of TrueType and
(PostScript's) CFF font and has some extra tables for a fine tuning of
the text layout. The coverage of the FreeType features is basically the
part *without* the extra tables. So if you can find something interesting
in ISO/IEC 14496-22, some can be found in FreeType2 documentations,
but others cannot be found.

--

I'm not familiar with the digital cinema technology, so hard to guess
the detail of your software. The decoder (appropriate term?) is running
on the general purpose operating systems? Or running on the set-top box
like systems? Is it possible to specify the appropriate font to render
the subtitles in the vertical writing mode?

Most current cinema systems seem to ignore vertical metrics. Instead, they
appear to place a fixed fractional amount of em between the bounding boxes
of characters. This works for most characters, but results in extremely
close spacing for punctuation, ichi, and other characters that do not use
the full cell.

Further, most systems are horizontally centering the
bounding box of each character around a vertical line (X=Hposition).
Again, this works for most characters, but results in incorrect rendering
of punctuation.

So, the resulted text is looking like "incorrect-123.png" in attachment?

It seems like we have found the Y offset between the horizontal origin and
the vertical origin in the VORG table or by adding the top side bearing to
yMax.

OpenType has a 2 types in it. One is an extended TrueType, including
"glyf" table which describes the glyph outlines by TrueType instructions.
Another is an extended CFF, including "CFF " table which describes the
glyph outlines by (PostScript-derived) CFF instructions. VORG table was
introduced for the CFF-based OpenType. The spec says as
"This table may be optionally present only in CFF OpenType fonts.
If present in OpenType fonts containing TrueType outline data,
it must be ignored."
( https://docs.microsoft.com/ja-jp/typography/opentype/spec/vorg )
Are you working with CFF-based OpenType for your system?

Anyway, in the design of the FreeType architecture, VORG table is regarded
as an extension in the OpenType, and FreeType does not reflect the info
written in VORG table in the metric calculation. It is similar to the kerning
info in GPOS table. Also, the data in BASE table is not reflected either.
It is not reflected in the FreeType metrics calculation, so you cannot
find anything any examples in FreeType documentations.

FreeType2 has a otvalid module which parse and validate the content of
some OpenType tables (BASE, GDEF, GPOS, GSUB, JSTF), but it does not support
VORG. Also it does not provide the public API to extract the specific value
from that. There was a light-wait library, libotf, to parse the OpenType
extended tables (used for earlier Emacs), but it does not support the VORG
either.

If you want to work with the info in the BASE and VORG table, you would have
to make your parser of them. FT2 can provide the memory image of those table
by FT_Get_Sfnt_Table(), but no API to parse the content. You would have to
parse it by yourself.

The x position of the top pen position in the vertical writing mode can
be calculated by (advance / 2) - bearingX, both can be obtained from hmtx
table.

Is bearingX the left side bearing? I'm not seeing why this would be
subtracted from the AdvanceWidth/2 . It seems that a glyph would typically
be centered between the horizontal origin and the horizontal origin plus
the advance width.

Oh, sorry. I made a mistake about the coordination system (I mistook the
origin of the coordination system as the lower left point of the glyph
bounding box). Yes, the half of AdvanceWidth is OK.

Regards,
mpsuzuki

On 2021/05/16 12:01, suzuki toshiya wrote:
Hi all,

I got a response from the original questioner, and forward it to the
list (with permission) for the continued discussion, I would try.

Regards,
mpsuzuki

-------- Forwarded Message --------
Subject: Re: [Freetype] Font files and vertical text
Resent-From: mpsuzuki@hiroshima-u.ac.jp
Date: Sat, 15 May 2021 19:51:07 +0000
From: Harold Hallikainen <harold@mai.hallikainen.org>
To: suzuki toshiya <mpsuzuki@hiroshima-u.ac.jp>

Sorry about the repeat! I hit send instead of save draft. Here's more of
the message.

Thank you for the excellent information! I am working with the Society of
Motion Picture and Television Engineers to try to improve the rendering of
Japanese subtitles in digital cinema. The FreeType tutorials have provided
me with a lot of the basics of how font files are interpreted.

Most current cinema systems seem to ignore vertical metrics. Instead, they
appear to place a fixed fractional amount of em between the bounding boxes
of characters. This works for most characters, but results in extremely
close spacing for punctuation, ichi, and other characters that do not use
the full cell. Further, most systems are horizontally centering the
bounding box of each character around a vertical line (X=Hposition).
Again, this works for most characters, but results in incorrect rendering
of punctuation.

It seems like we have found the Y offset between the horizontal origin and
the vertical origin in the VORG table or by adding the top side bearing to
yMax.

The X offset between the horizontal origin and the vertical origin seems
more difficult.

ISO/IEC 14496-22 2019-1 section 5.7.10 says "The x coordinate of a glyph's
vertical origin is not specified in the 'vmtx' table. Vertical writing
implementations may make use of the baseline values in the Baseline
('BASE') table, if present, in order to align the glyphs in the x
direction as appropriate to the desired vertical baseline.

Section 6.3.1 describes the BASE table as "The Baseline table (BASE)
provides information used to align glyphs of different scripts and sizes
in a line of text, whether the glyphs are in the same font or in different
fonts. To improve text layout, the Baseline table also provides minimum
(min) and maximum (max) glyph extent values for each script, language
system, or feature in a font."

It goes on to state:

Within the BASE table, a BaseCoord table defines baseline and min/max
extent values. Each BaseCoord table defines one X or Y value:

If defined within the HorizAxis table, then the BaseCoord table contains a
Y value.

If defined within the VertAxis table, then the BaseCoord table contains an
X value.

It appears this is the correct location to determine the X value of the
vertical origin (X offset from the horizontal origin).

However, I have not seen any further documentation suggesting this, hence
my questions to the FreeType list.

You previously said:
The x position of the top pen position in the vertical writing mode can
be calculated by (advance / 2) - bearingX, both can be obtained from hmtx
table.

Is bearingX the left side bearing? I'm not seeing why this would be
subtracted from the AdvanceWidth/2 . It seems that a glyph would typically
be centered between the horizontal origin and the horizontal origin plus
the advance width.

Looking at a typical character in a Japanese font file I have, I see:

xMin = 143

xMax = 1907

AdvanceWidth = 2048 (1 em)

This makes the left side bearing 143 and the right side bearing 141. The
character is almost centered in the advance width, so I'd expect the
vertical origin to be somewhere around 1024 (centered above the
character).

On the comma position variation between vertical and horizontal text, I
guess that is typically handled by the glyph substitution table. Existing
cinema subtitle rendering systems do not seem to make use of that table.

THANKS for all the information! I really appreciate your help in my
understanding how this works. I will have a look at the documents you
referenced.

Harold





Dear Mr. Hallikainen,
On 2021/05/15 4:47, Harold Hallikainen wrote:
I am trying to understand how font files are used when writing
vertically
(such as for Japanese text). I'm pretty new to this, so please excuse
my ignorance.
Thanks, but I suggest, please do not try to understand it completely by
FreeType document. The modern applications trying to support the CJK
vertical writing mode use more complicated frameworks, like HarfBuzz. The
support of CJK vertical writing mode in FreeType is very fundamental
level. No line breaking, no auto-rotation, etc etc.
https://www.freetype.org/freetype2/docs/glyphs/glyphs-3.html shows the
horizontal and vertical baselines for horizontal and vertical text. I
THINK the glyph "drawing instructions" are relative to the horizontal
origin. When writing horizontally, the horizontal origin of a character is
placed at the pen position passed into the renderer, and the glyph is
drawn with reference to that position. The next character starts with its
pen position at the old pen position plus the AdvanceWidth.
For vertical text, it looks like there is a vertical origin that is
typically centered above the glyph. The Y offset from the horizontal
origin is either in the VORG table or can be calculated from yMax and the
top side bearing. It is very unclear to me how one determines the X
offset
from the horizontal origin to the vertical origin. Is there a drawing
or something that shows how this is done? When rendering vertical text, I
assume the renderer is passed a pen position for the top character. The
renderer then applies the offset to get to the horizontal origin and draws
the glyph based on the horizontal origin (just as for horizontal text).
Is
this anything close to correct?
The x position of the top pen position in the vertical writing mode can
be calculated by (advance / 2) - bearingX, both can be obtained from hmtx
table.
The y position of the top pen position in the vertical writing mode,
measured in the glyph-internal coordinate system, can be calculated by
yMax + bearingY. The bearingY can be obtained from vmtx table. The yMax
can be obtained from the glyph instructions.
Each glyph instruction in the glyf table has its header, which provides
the glyph bounding information, xMin, yMin, xMax, yMax.
Character positions in a cell change depending on whether the character
is
in a horizontal or vertical string. For example, in Japanese, the comma
in
horizontal text is low and to the left (so it "hugs" the previous
word).
Such features are now regarded as a part of the line breaking features,
it is the task of the text layout system in the higher layer,
not the task of the FreeType rendering a glyph image from a font file.
Please take a look on Unicode Standard Annex #50 (to figure the
terminology),
JLReq (https://www.w3.org/TR/jlreq/ to see the tons of the conventions
which Japanese experts hope). They are totally too much to put in
FreeType.
In vertical text, it is high and to the right (so it, again, "hugs" the
previous word since text reads top to bottom and columns right to
left). It sees that this difference could be handled by changing the
offset between the horizontal and vertical position. It could also be
handled through glyph substitution. It could also be handled through the
use of a
separate Unicode code point (for example, U+3001 for horizontal text
and U+FE11 for vertical text).
Using or avoiding the compatibility characters in Unicode is highly
dependent with the (computational) cultural region. These vertical glyphs
in the compatibility characters were introduced for legacy
character encodings in PRC or Taiwan, not those in Japan. Japanese
industrial character sets do not separate the codepoints for the glyph for
the horizontal and vertical writing mode, so most plain texts
produced by the software customized for Japanese market do not include
U+FE11, at least, most users are not trained how to input them.
Hope if I could answer some of your questions.
Regards,
mpsuzuki


Attachment: incorrect-123.png
Description: PNG image


reply via email to

[Prev in Thread] Current Thread [Next in Thread]