Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Chinese Characters not well aligned with 'vpal' feature enabled #485

Closed
KrasnayaPloshchad opened this issue May 15, 2017 · 13 comments
Closed

Chinese Characters not well aligned with 'vpal' feature enabled #485

KrasnayaPloshchad opened this issue May 15, 2017 · 13 comments
Labels
Vertical Vertical text direction

Comments

@KrasnayaPloshchad
Copy link

KrasnayaPloshchad commented May 15, 2017 •
edited
Loading

I have tested hb-view with Source Han Serif font, if 'vpal' feature enabled, then Chinese Characters not centered, and the height have not been changed.
test
They should works as this (found at Type is Beautiful):
sample
@behdad
Copy link
Member

behdad commented May 16, 2017

Assigning to @kenlunde to see if he can figure out what's going on. I have no idea and no time to debug any time soon.

@kenlunde
Copy link

@behdad: The glyph for a single ideograph, U+4E00 一, is included within the scope of the 'vpal' GPOS feature. The following is my raw (using Unicode-based working glyph names) "features" file code for this glyph:

position uni4E00-CN <0 140 0 -280>;

The second element adjusts lowers the Y-axis origin by 140 units, whose effect is to raise the glyph by 140 units. The fourth element trims 280 units from the vertical advance, making it 720 units. The end result is that 140 units are trimmed from both the top and bottom of the glyph.

@KrasnayaPloshchad
Copy link
Author

So HarfBuzz need to handle all four elements to clip the glyph when this feature is activated. BTW I found HarfBuzz has the similar problem for 'vhal' feature.

@kenlunde
Copy link

The 'vert' GPOS (not GSUB) feature also uses the same four elements, so it needs to be checked, too. However, given that U+3001 、 IDEOGRAPHIC COMMA seems to behave correctly and is handled via the same feature ('vpal'), I wonder whether something else it at work here.

@behdad
Copy link
Member

behdad commented May 18, 2017

We seems to be applying GPOS just fine. However, neither FreeType nor hb-ot-font implement VORG table. I don't know what the reporter's screenshots are coming from, but probably same issue. Without VORG, it's not possible to correctly get the vertical glyph origin..

@KrasnayaPloshchad
Copy link
Author

KrasnayaPloshchad commented May 19, 2017 •
edited
Loading

I don't know what the reporter's screenshots are coming from, but probably same issue.

The first screenshot generated directly by hb-view.exe; the second image found at Type is Beautiful, according to TIB, this screenshot came from Adobe Illustrator to show the effect when enabling 'vpal' feature in SHS font.

@KrasnayaPloshchad
Copy link
Author

So this can be consider as duplicate of #250, isn’t it?

@behdad
Copy link
Member

behdad commented Oct 4, 2017

What's the text sequence?

@behdad
Copy link
Member

behdad commented Oct 4, 2017

Looks like #416

Ie. hb-shape is fine, hb-view is wrong.

Also this: #537

@KrasnayaPloshchad
Copy link
Author

What's the text sequence?

You can copying from here:
公元二一三年、十一月

marklh9 added a commit to marklh9/harfbuzz that referenced this issue Nov 17, 2017
@marklh9
attempt to offset vertical glyphs (harfbuzz#575) (harfbuzz#485)
e9416a2 
This patch would fix incorrect glyph position
highlighted in https://imgur.com/a/I0jJU as well
as in harfbuzz#485. I try to explain my point of view
and would like to know if I'm correct.

Note: for harfbuzz I have do some cairo translate.
In LibreOffice I don't. I don't know why.

Original issue is to fix text offset issue of
vertical writing in LibreOffice after LibreOffice
update its HarfBuzz from 1.3.3 to 1.4.8. I tried
to figure out how to use those values emprically.

Y_offset was 0 with HarfBuzz 1.3.3 and has
become -1160 (roughly 1EM upward) after upgrade to
1.4.8, I suspect that the offsets returned by Harfbuzz
are always repect to h_origin:

subtract_glyph_v_origin()
-> get_glyph_v_origin_with_fallback
-> guess_v_origin_minus_h_origin

But underlying renderer might expect positions relative
to the vertical origin. To compensate the result
I try to translate them back by calling
hb_font_add_glyph_origin_for_direction(),
to add the horizontal origin, hence make offset
relative to the v origin.
@marklh9 marklh9 mentioned this issue Nov 17, 2017
Closed
@KrasnayaPloshchad
Copy link
Author

Here is my test with hb-view 2.1.1
harfbuzz-2.1.1-win32\hb-view.exe C:\Windows\Fonts\SourceHanSerifSC-Regular.otf --unicodes="516C 5143 4E8C 4E00 4E09 5E74 3001 5341 4E00 6708" --features=vpal --direction=ttb --output-format=png --output-file=test.png
test

@KrasnayaPloshchad
Copy link
Author

After I got HarfBuzz 2.2.0, the problem is still there. So what’s wrong with it?

@behdad behdad added the Vertical Vertical text direction label Jan 19, 2022
@behdad
Copy link
Member

behdad commented Jun 24, 2022

This also seems fixed to me.

@behdad behdad closed this as completed Jun 24, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Vertical Vertical text direction
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@behdad @kenlunde @KrasnayaPloshchad