Hello,
I am moving from Pango to Harfbuzz for my typesetting application, but have
noticed a difference in the output - in particular, the spacing between glyphs
is not right; I think I must be doing something wrong in the rendering step.
I set the fonts up like so:
if
On 13/09/2014 13:39, Martin Hosken wrote:
What version of harfbuzz-ng?
I've tried:
0.9.27 from Homebrew
0.9.35 from Homebrew (neither of which built with graphite2)
Harfbuzz HEAD with graphite2.
No change.
Did you compile it --with-graphite2?
Perhaps this is a
On 13/09/2014 17:05, Simon Cozens wrote:
Deeper and deeper.
The problem is, of course, that I am an idiot. Nothing to do with scaling or
Graphite or Harfbuzz.
This line in my code while configuring fontconfig
if (f-slant)
FcPatternAddInteger(p, FC_SLANT, f-slant);
meant
I don't know if this is a HB question or a general font/PDF question,
but I am trying to shape some Tibetan text with combining characters and
I can't get it working.
When I try to shape the diglyph སྐ (TIBETAN LETTER SA U+0F66, TIBETAN
SUBJOINED LETTER KA U+0F90) in the Kokonor font I get back
On 28/11/2014 18:22, Martin Hosken wrote:
Is it that the Kokonor font has the diacritics as overstriking, i.e.
with a negative x-min (and probably x-max too)? This would account
for all the advance being on the base character and none on the
diacritic.
Huh. Well, in *that* case, Harfbuzz (or
Hello! I am working on adding vertical typesetting support to SILE, and
have come across a couple of issues.
The first is that all characters with direction set to TTB seem to have
x_offset and y_offset positions set even when this does not make sense:
a = aあ
SILE.call(font, { family = MS
On 12/06/2015 09:17, Behdad Esfahbod wrote:
This happens because HarfBuzz thinks your font instance is set for horizontal
typesetting. That is, this returns offsets that work with a font that has
origin at baseline-left. What you expect instead can be achieved by
configuring the font to use
---
src/hb-buffer-serialize.cc | 17 +
src/hb-buffer.h| 3 ++-
util/hb-shape.cc | 2 ++
util/options.cc| 2 ++
util/options.hh| 2 ++
5 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/src/hb-buffer-serialize.cc
On 24/08/2015 13:32, Behdad Esfahbod wrote:
Should we move the extents to reflect the glyph position? Just add the
offset? Or both offsets and advances?
I'm not sure I understand - offsets/advances are where you put the box,
extents are how big the box is. One shouldn't affect the other,
More details at https://github.com/simoncozens/sile/issues/164 , but in
a nutshell, using Noto Sans CJK JP and TTB direction, Ubuntu 12 gives:
$ md5sum ~/.fonts/NotoSansCJKjp-Light.otf
f269c193b1ef0b739030d56386670c3f /home/simon/.fonts/NotoSansCJKjp-Light.otf
$ hb-shape --direction=ttb
On Aug 2, 2015, at 18:08, Jonathan Kew jfkth...@gmail.com wrote:
Which suggests there's something odd about how you're using harfbuzz.
Ok, that makes sense. And yes, I was ignoring the advance for glyphs and
instead using Freetype to return the glyph width. I think I stole that bit of
code
On 08/08/2015 16:31, Behdad Esfahbod wrote:
The 'm' has advance of 1645 units in a 2048-unit font. At 10pt, that means:
1645 / 2048. * 10
8.0322265625
So we're losing something on the way. How do you setup the font scale? Show
me the code.
In general, for something like Sile, you
On 09/08/2015 09:15, Simon Cozens wrote:
OK, I'm now trying to set the scaling to the font upem, but I'm not
getting that working either.
After a bit of fiddling I have now got it working, using:
hb_face_t* hbFace = hb_ft_face_create_cached(face);
hb_ft_font = hb_font_create (hbFace
On 16/07/2015 16:21, aronsoyol wrote:
When shaping it with top to bottom direction and paint it. As you
see the orientation of number 2015's glyph is not expected. they
should be rotated 90 degrees
Actually I would expect exactly what you got, although it would look
better if you had used the
On 27/10/2015 00:37, Nikolay Sivov wrote:
> But probably more important is that this functionality doesn't seem
> to belong to harfbuzz in a first place, as it never needs global
> metrics internally (or does it?).
No, it doesn't need these metrics internally. If Harfbuzz just sticks to
text
So this is no longer really a HB question any more; sorry. If there is a
better place to discuss general text layout issues, please point me
there instead, but I think most of the people who know about the subject
are here...
On 27/10/2015 01:42, John Labovitz wrote:
> What’s far more important
Can anyone point me at some sample code which allows performs font
substitution? I'm guessing the way to do this is to detect notdefs,
break the buffer around them and then try the notdef'd glyphs in another
font. Has anyone got some fairly accessible code which does this already?
S
On 05/11/2015 14:57, Behdad Esfahbod wrote:
> Simon, this should speed up your use case more than anyone else's. Can you
> please share numbers?
With 1.0.6, test.sil (Latin text) took 6.1s; a stripped-down version of
Khaled's Arefruqaa test file (30,000 lines of Arabic) took 59.1s
With HEAD,
On 10/10/2015 01:33, Jonathan Kew wrote:
> You probably want to be using the "typographic" metrics from the OS/2
> table, if present, with the hhea metrics as a fallback for fonts that
> don't have OS/2. (They're rare, but can exist at least on OS X.)
Hmm... that's something it doesn't look like
On 09/10/2015 15:09, Khaled Hosny wrote:
> On Thu, Oct 08, 2015 at 11:54:09AM -0400, Behdad Esfahbod wrote:
>> So, from my
>> point of view, you should NOT use this for line height calculation. You
>> should just use the typographical
Hello!
I don't know if the following is a font problem or a Harfbuzz problem.
Mongolian is written top to bottom - like Japanese but with the columns
left to right. It's also joined with initial, medial and final forms
like Arabic.
When I shape Mongolian text with direction set to LTR, I get
So I'm using Harfbuzz to shape stuff and put it out to PDF. When you
output a string in PDF, you are expected to kern it manually, or else
each glyph will be placed one after the other with no kerning:
No kerning: Td (VAVAVOOM) Tj
Kerning: Td[(V) 153 (A) 122 (V) ... ]TJ
The numeric values
On 04/09/2015 15:50, Behdad Esfahbod wrote:
> You need the advance width, and you can get that using
> hb_font_get_glyph_h_advance().
Aha! And the kerned adjustment is the difference between the glyph's h
advance and the shaped x_advance... Yes, that seems to work. Thank you!
On 04/09/2015 16:32, Nikolay Sivov wrote:
> I think it's only true if kerning is the only advance adjustment that
> shaper applied, and you can only guess if it's true or not. So this
> difference is more like accumulated adjustment, not necessary caused by
> kerning.
I think for my purposes
On 03/10/2015 01:51, Behdad Esfahbod wrote:
> So, how does that sound? I expect that it will only make easier for most
> clients. Like to hear what Jonathan has to say. Chrome, Android, Pango,
> XeTeX, Sile should all either benefit from this or be unaffected.
This all sounds great but if it's
The Lanna for Lanna is "ᩋᩣᨱᩣᨧᩢᨠᩕᩃ᩶ᩣ᩠ᨶᨶᩣ"[*].
I'm getting very different renderings of that string in Safari, Firefox
and hb-shape, using the same fonts. I don't know which is correct.
Notice in the attached PNG that not only is HB giving me no-base-glyph
dotty circles, the MEDIAL RA (the thing
On 24/12/2015 07:37, Jonathan Blow wrote:
> When I look at this diagram from the
> FreeType documentation:
>
> http://www.freetype.org/freetype2/docs/tutorial/step2.html
>
> It says that wherever the cursor is, add bearingX as an offset and draw
> the thing in the box.
No, it doesn't. That
On 24/12/2015 11:39, Deepak Jois wrote:
> Here is an old thread that I have bookmarked, regarding whatever little
> documentation that does exist:
>
> http://lists.freedesktop.org/archives/harfbuzz/2015-August/005036.html
When Khaled's PR lands, there'll be docs available at
On 24/12/2015 15:21, Khaled Hosny wrote:
> The problem is that you are mixing “render glyph” internal with the rest
> of this flow chart.
The confusion comes from the fact that Jonathan seems to be writing a
glyph rendering library. From his perspective, yes, you need to add
offsets to bearings
On 14/06/2016 14:23, kelvinsthirt...@gmail.com wrote:
> each word has at least
> one (often many) breakpoints, but only one of them gets used per
> line.
Right.
> And the only way to know which one to use is to shape.
Well, no. You shaped already; that was the first thing you did. As Adam
told
On 14/06/2016 13:16, Kelvin Ma wrote:
> The problem is, I have no idea where, in terms of x-coordinate, any of
> these breakpoints are going to be until I shape them. So I will have to
> shape the entire sentence.
You do have to shape the entire sentence, yes. But that's got nothing to
do with
On 14/06/2016 01:00, Kelvin Ma wrote:
> So I’ve not received an answer to this anywhere, so, how do I typeset
> paragraphs with Harfbuzz?
http://behdad.github.io/harfbuzz/hello-harfbuzz.html#what-harfbuzz-doesnt-do
Sorry, I need to finish writing the manual; will have more time soon.
Simon
On 26/06/2016 06:52, Kelvin Ma wrote:
>
> ['t', 'h', 'i', 's', ' ', {FONT_POSITIVE: 'bold'}, 'i', 's', ' ', 'b',
> 'o', 'l', 'd', 'e', 'd', {FONT_NEGATIVE: 'bold'}, ' ', 't', 'e', 'x', 't']
You don't need to send your internal representation to Harfbuzz. If it's
a problem, you could always send
On 25/04/2016 07:22, Khaled Hosny wrote:
> This leaves Han which has its own OpenType tag and that is what I have
> been seeing most. So I wounder what other application do, should I try
> something clever like see what scripts/features/lookups are in the font
> and decide to merge the scripts if
On 25/04/2016 08:05, Khaled Hosny wrote:
> The problem with merging is which script tag to select for the merged run,
> Kana or Hani or “it depends on the font”.
Why does it matter what script tag to apply if there are no opentype
interactions with Japanese?
On the other hand, I have just
On 30/04/2016 13:06, Muller, Eric wrote:
> I suspect that font developers who have used 'kana' will have to touch
> their fonts in many cases, so there may be little benefit in trying to
> extend 'kana'.
Do you have an example of a Japanese font which does something
OpenType-ly interesting with
On 29/06/2016 06:57, Kelvin Ma wrote:
> How do I get harfbuzz to preserve the floats?
There are no floats. Fonts are designed in integer units. What upem are
you using?
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
On 02/07/2016 07:34, Kelvin Ma wrote:
> So I think I figured out how to turn on font features, but how do I turn
> ones off that are enabled by default? Like liga or kern?
Just set the value to 0 in the features array.
See
On 05/12/2016 13:56, Ondřej Majerech wrote:
> So the question is, what am I doing wrong in my program that makes
> HarfBuzz report such low x_offset values?
There's a couple of things here.
The first is:
> std::cout << name_buffer << ": "
> << "x_advance = " <<
On 12/05/2019 05:15, Eli Zaretskii wrote:
OK, thanks. I think this is a large chunk of the solution to my
problem...
Also, does HarfBuzz support TrueType Collection (TTC) files, and if
so, does it want the data only for the currently selected font or all
of the data?
Assuming you're still
On 12/02/2020 19:28, Aleš Mlakar wrote:
> I did a quick debug through that part of HarfBuzz and it seems it's
> doing lookups and never gets to the random code.
OpenType randomization on the whole isn't *really* random. Most fonts
implement pseudo-random selection of alternate glyphs by going
On 14/02/2020 15:50, Aleš Mlakar wrote:
So, as far as I can understand all of this either one of Indesign or
Harfbuzz is doing it wrong.
Without having the font or its feature code, it's very hard for someone
else to debug.
S
___
HarfBuzz mailing
On 14/02/2020 16:56, Jonathan Kew wrote:
If the font you're talking about is
https://www.myfonts.com/fonts/pintassilgo/daft-brush?tab=techSpecs, then
it does claim to include a 'rand' feature.
That would explain it, then.
I don't know how InDesign attempts to use 'rand' (if at all)
My
On 23/05/2020 08:44, Eli Zaretskii wrote:
Thanks. Since (b) is not really feasible without redesigning the
entire Emacs display engine (for which I see no volunteers lining up
any time soon), I guess we will have to use some more-or-less
reasonable and somewhat unreliable heuristics by
44 matches
Mail list logo
