Closed ctrlcctrlv closed 3 years ago
Which particular differences did you notice? Different glyphs in the output or positioning information (or something else)?
The positioning wasn't even checked by me to be correct because it's choosing the wrong glyphs.
"Shape me!" (using glyphs [S|h|a|p|e|space|m|e|exclam]
)
"Shape me!" (using GSUB rules w/feature ccmp
: [S.rhigh|h.high|a.low|p.low|e.low|tail.low|space|m|e.low|tail.low|exclam]
)
hb-shape
command line which will just show you the glyphs:
hb-shape dist/FRBAmericanCursive-400-Regular.otf "Shape me!" --no-positions --ned
The thing about this font is that even a single Latin letter needs GSUB to render correctly, to get the tail.
$ hb-shape dist/FRBAmericanCursive-400-Regular.otf "a" --no-positions --ned
[a|tail.lowwide]
$ hb-shape dist/FRBAmericanCursive-400-Regular.otf "a" --no-positions --ned --features=-ccmp
[a]
Another font of mine that requires GSUB to render correctly is TT2020.
[fred@laptop FRBAmericanCursive]$ hb-shape ../TT2020/dist/TT2020StyleB-Regular.ttf "Shape me!" --no-positions --ned
[S|h.2|a.3|p.4|e.5|space.6|m.7|e.8|exclam.9]
But the command ~/Workspace/allsorts-tools/target/debug/allsorts shape -f ../TT2020/dist/TT2020StyleB-Regular.ttf -s DFLT -l dflt "Shape me!"
results in similarly bad output.
Thanks for the info. I'll look into it. I'm pretty confident that it will work one way or another. It's possibly a limitation of the allsorts
binary as opposed to the library. If I feed this document into Prince (which uses Allsorts for font parsing and shaping) I get the right output.
<html>
<head>
<style>
@font-face {
font-family: "FRB American Cursive";
font-weight: normal;
font-style: normal;
font-stretch: normal;
src: url("/home/wmoore/Downloads/FRBAmericanCursive/dist/FRBAmericanCursive-400-Regular.otf")
}
body {
font-family: "FRB American Cursive";
font-size: 48pt;
}
</style>
</head>
<body>
<p>Shape me!</p>
</body>
</html>
That is interesting. Could it be failure to fallback when script/lang is DFLT/dflt?
Ok so I looked into it and as far as I can see the Allsorts output matches Harfbuzz, it's just that the output we generate is different to hb-shape
.
$ allsorts shape -f ~/Downloads/FRBAmericanCursive/dist/FRBAmericanCursive-400-Regular.otf -s dflt -l DFLT "Shape me" | grep glyph_index
glyph_index: 55,
glyph_index: 314,
glyph_index: 79,
glyph_index: 356,
glyph_index: 285,
glyph_index: 393,
glyph_index: 386,
glyph_index: 331,
glyph_index: 285,
glyph_index: 393,
$ hb-shape ~/Downloads/FRBAmericanCursive/dist/FRBAmericanCursive-400-Regular.otf "Shape me" --no-glyph-names --no-positions
[55=0|314=1|79=2|356=3|285=4|393=4|386=5|331=6|285=7|393=7]
Comparing these you can see that the same glyphs are present after shaping.
Would you accept a patch to output the glyph name and not just its index?
If the idea is to resolve the glyph name from the glyph id in the output glyphs within allsorts-tools
then I think that would be fine. Currently the shaping output is just a Debug
dump of the Vec
of glyphs, so there's plenty of room for improvement.
There's already some glyph name related code present for the dump
sub-command that might be a useful reference.
Thanks. I'll try to open a PR to do that. :)
Considering this closed because as you showed the glyph indexes are actually correct, I was just reading the output wrong.
Comparison of hb-shape and allsorts against my font, FRB American Cursive:
allsorts
hb-shape