Re: [HarfBuzz] Ligatures
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 supporting only some ligatures that are known in advance. Travelling further in the wrong direction is always an option, but don't expect it to get you closer to the right destination. Full text shaping is the only way to get this right. Everything else is a hack, and piling hacks on top of hacks is just storing maintenance problems up for yourself. I know that's hard to hear for a volunteer project where nobody really wants to invest the effort in this complicated niche stuff, but honestly, you're probably better doing *nothing* than doing this. ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Alternate/random glyphs
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 understanding is that it doesn't implement it. there is no expectation that it will produce consistent results from one application to another, or one document to another (or even in repeated rendering of the same document). Well, quite. "A font which includes randomization produces different results sometimes" should probably be considered a feature, not a bug :-) S ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Alternate/random glyphs
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 list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Alternate/random glyphs
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 through a series of lookup rules (see e.g. the bottom of http://opentypecookbook.com/common-techniques.html ). As you can see, none of the techniques there actually use any source of randomness; they just apply deterministic rules to the input stream. There *is* a "rand" feature in the OpenType standard, which asks the shaper for non-deterministic random selection, but for this to work, two things need to be in place: the shaper needs to support it, and the font needs to define it. Harfbuzz as a shaper supports it, but no others do. Because of this, few fonts define it. Even then, Harfbuzz's random number implementation is only pseudorandom with a fixed random seed, so you get the same results each time anyway. I don't know whether Daft Brush uses the "rand" feature. It probably doesn't. Although if you are seeing differences between harfbuzz and InDesign, it might be that it does. In short it is down to the font. S ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] How to get hb_face_t and hb_font_t without Freetype?
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 stuck, have a look at the "shape" function in https://github.com/simoncozens/sile/blob/master/src/justenoughharfbuzz.c The parameters (lua-wrapped) are: text to shape, as a string; the binary contents of the font file; the index of the font in a TTC; the script code, direction as a string, language code, point size, and any list of features. Simon ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] x_offset too small for a combining character
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 = " << (positions[i].x_advance / 64) > << ", y_advance = " << (positions[i].y_advance / 64) you're using integer math here. 64.0 will give you more precise answers: q: x_advance = 10.1562, y_advance = 0, x_offset = 0, y_offset = 0 dotbelowcomb: x_advance = 0, y_advance = 0, x_offset = -1.09375, y_offset = -3.34375 uni0307: x_advance = 0, y_advance = 0, x_offset = -1.28125, y_offset = 0 But you're also confusing pixels and points. If you're really working at a resolution of 96 pixels per inch, as you say here: > FT_Set_Char_Size(face, 12 << 6, 12 << 6, 96, 96); Then your dotbelowcomb needs to be adjusted by -1.09375 * 96 = -105 pixels. ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Turning off ligatures and kerning
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 https://github.com/simoncozens/sile/blob/master/src/justenoughharfbuzz.c#L78 Simon ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] How to increase harfbuzz numerical precision
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 https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Setting initial cluster value
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 something else instead.
In fact, you will need to, because bold characters usually have
different metrics to regular ones.
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Fwd: Harfbuzz with linebreaking
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 you, the only way to know which breakpoint to *use* is to run a justification algorithm, which you need to code. You're currently thinking about a simple first-fit algorithm, which chops the glyphs into lines once they get to be longer than the target line length; that's fine, although you may find that a best-fit algorithm which performs dynamic programming over all possible breakpoints gives you a neater paragraph. Now, shaping determines the glyph widths for you (which is the input to your line breaking algorithm), but it is your code which is responsible for finding the *possible* breakpoints in the text, at the language level, and your code which is responsible for determining the *actual* breakpoints at the shaped-glyph level. Here we go then. If you want to use Harfbuzz to shape lines into paragraphs, here is what you need to do: * Perform the first stage of the bidi algorithm to organise the text into same-direction runs. (Really, don't leave this bit out, and don't think "I'll add RTL/complex script support later", because that never works out well and because we already have enough typesetters that only handle Latin.) ICU does this. * Shape the paragraph, keeping note of the connection between the glyphs and the text. Harfbuzz does this. * Find the breakpoints in the text, using language analysis on the characters. ICU does this. * Create a data structure representing the runs of Harfbuzz output between the breakpoints - TeX and SILE call these runs "nnodes" - and the potential breakpoints themselves - "penalty nodes" (for breaking inside a "word") and "glue nodes" (for whitespace between "words"). Assign widths to the nnodes by summing the widths of the shaped glyphs inside them. You can put each glyph into its own nnode instead of consolidating each run into an nnode if it's conceptually easier, but it just slows your justification algorithm down. Here's what my data structure looks like at this stage: N<19.71pt>(Take)G<2.6pt>N<22.06pt>(these)G<2.6pt>N<15.37pt>(five)G<2.6pt>N<40.42pt>(sentences)G<2.6pt>N<25.17pt>(which)G<2.6pt>N<2.97pt>(I)G<2.6pt>N<19.95pt>(need)G<2.6pt>N<8.47pt>(to)G<2.6pt>N<23.24pt>(break)G<2.6pt>N<16.69pt>(into)G<2.6pt>N<4.58pt>(a)G<2.6pt>N<42.68pt>(paragraph)N<2.29pt>(.) (Each nnode also contains a list of glyph IDs and widths.) Each of the glue nodes are potential break points; these were obtained by checking the Unicode line break status of each character. The space character 0x20 is breakable, so it gets turned into a glue node. * Run your justification algorithm to determine which breakpoints should be used. Your code does this. * If the algorithm does not produce a tight enough paragraph, break open the nnodes by hyphenating the text, reshaping them into new nnodes, and putting a discretionary breakpoint in the middle. Now it looks like this: N<19.71pt>(Take)G<2.64pt>N<22.06pt>(these)G<2.64pt>N<15.37pt>(five)G<2.64pt>N<13.99pt>(sen)D(N<3.36pt>(-)||)N<26.43pt>(tences)G<2.64pt>N<25.17pt>(which)G<2.64pt>N<2.97pt>(I)G<2.64pt>N<19.95pt>(need)G<2.64pt>N<8.47pt>(to)G<2.64pt>N<23.24pt>(break)G<2.64pt>N<16.69pt>(into)G<2.64pt>N<4.58pt>(a)G<2.64pt>N<18.43pt>(para)D(N<3.36pt>(-)||)N<24.24pt>(graph)N<2.29pt>(.) * Run your justification algorithm again on this new node list. On a 100pt column, my algorithm determined that the line breaks are at position 10 and position 22 of the node list array. * Organise your node list into a list of lines, based on the breakpoints that were fired. I split my node list at positions 10 and 22, so my lines are: N<19.71pt>(Take)G<2.64pt>N<22.06pt>(these)G<2.64pt>N<15.37pt>(five)G<2.64pt>N<13.99pt>(sen)D(N<3.36pt>(-)||)N<26.43pt>(tences)G<2.6pt> N<25.17pt>(which)G<2.6pt>N<2.97pt>(I)G<2.6pt>N<19.95pt>(need)G<2.6pt>N<8.47pt>(to)G<2.6pt>N<23.24pt>(break)G<2.6pt>N<16.69pt>(into) N<4.58pt>(a)G<2.6pt>N<18.43pt>(para)D(N<3.36pt>(-)||)N<24.24pt>(graph)N<2.29pt>(.) * For each line in the paragraph, apply the second part of the bidi algorithm (ICU does this) and reshape where necessary. This splits and recombines ligatures correctly. (I promise; we have a test case to prove this.) You only need to determine line breaks once, and you only need to reshape once per line maximum. I'm not going to argue about whether it works or not, because you can check out the code and the test suite for yourself: https://github.com/simoncozens/sile > In fact I don’t see any other way to do it You need to put aside the idea that there is a connection between shaping and determining which breakpoints to use. There isn't one, and this is the mental block which is stopping you from seeing solutions to your problem. Simon
Re: [HarfBuzz] Fwd: Harfbuzz with linebreaking
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 where your breakpoints are. Shaping doesn't tell you anything about break points. That's why it's not Harfbuzz's job. Let's take your example again. How do you get from: > Take these five sentences which I need to break into a paragraph. The > shaper is always going to be involved in this. Did you only count two? to: > |Take |these |five |sen-|ten|-ces |which |I |need |to |break |into |a > |para-|graph. |The |sha-|per |is |al-|ways |go-|ing |to |be > |in-|vol-|ved |in |this. |Did |you |on-|ly |count |two?| Shaping won't give you the hyphenation points. That's a matter of language analysis. So you have to do line breaking at the text layer; this is *why* Harfbuzz doesn't involve itself in line breaking. > You are right. But I hope I explained why the shaping information has to > come before the textual-breakpoint information, because without shaping, > you don’t know *where* the breakpoints lie Even with shaping, you don't know where the breakpoints lie. Shaping and breakpoints are completely orthogonal. And line breaking *will* change your shaping - think about what happens when you break an RTL Hebrew sentence inside a majority LTR text - you need to swap around the two ends of the sentence. The safe-to-break API is just an optimization; it says, if you break at this point, you won't have to reshape. But it doesn't tell you anything about where you *should* or *shouldn't* break - that depends entirely on your justification strategy. Simon ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Harfbuzz with linebreaking
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 ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Itemising Japanese scripts
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 the "kana" script specifically and not with the DFLT script? I am having difficulty imagining what it might look like, and if this is actually a live issue. ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Itemising Japanese scripts
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 it is safe (i.e. merging or not should > have no effect on features applied), or should I just leave the current > behaviour and not worry about it? Just merge them. From an OpenType perspective, Japanese is boring. Japanese characters are treated as discrete, independent units except in extreme cases, (e.g. Kazuraki which uses ligatures to attempt to replicate a hand-written look) so there should not be any OpenType interactions between characters. I remember Paul Hunt saying that when they developed Kazuraki they had to rewrite chunks of their OpenType shaper to deal with it, as it was such a special case. *Even if* there are OpenType interactions, these should take place within the context of a Japanese font which has both kana and kanji sets, so merging would be the right thing to do. The real fun you're going to have is getting the layout correct, but you can look at my code for how to implement that. :-) ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Itemising Japanese scripts
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 remembered one interaction: a pan-CJK font such as Source Han Sans / Noto Sans CJK will have variant forms of the kanji for Chinese, Japanese and Korean. But even then the selection should be done on language, not on script - I haven't checked how it works. So if pushed I would say Kana, just in case. But it really shouldn't matter. ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] HarfBuzz glyph offsets
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 documentation doesn't tell you anything about how to lay out text. It is explaining glyph metrics - telling you about how various things inside a glyph are measured. In that diagram, it says that the measurement between the origin and the left bit of black ink inside the glyph is called bearingX. But most people don't need to care about that! > I am not able to conceive of any version of "render glyph" whose > implementation does not involve adding horiBearingX Can you show your code? What are you using to turn the glyph onto pixels on the screen? Normally people doing text layout don't do that bit themselves - they use a third party rendering library to do it. *That* library needs to care about sidebearings, but those of us working on the text layout layer just need to worry about where the box starts and where the next box is. This is how offsets and bearings are different: an offset says "for correct text rendering, you will need to shift this particular box a bit." Within that (shifted) box, the text rendering layer will *still* need to apply the correct bearings for the glyph that you've shifted - but again, you don't need to care about that. > But since there doesn't seem to be any real HB documentation anywhere > that I can find, I don't really know. I'm sorry about this. There is the beginnings of a user manual. (did you build the docs when you built Harfbuzz?), and Khaled is working on publishing it on the web. I am trying to complete it, but I am insanely busy with life stuff at the moment. I should have more time in February. ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] HarfBuzz glyph offsets
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 http://behdad.github.io/harfbuzz/ (In the meantime the docs are at http://khaledhosny.github.io/harfbuzz/ - like I said, sorry I've dropped the ball on the user manual. As well as the skeleton that's there, there's an awful lot more I need to add to it. But finding the time...) Behdad, any reason this shouldn't be merged? ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] HarfBuzz glyph offsets
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 to position the black bits of a glyph correctly. All completely correct. The *problem* comes from the fact that he's mixing layers and using Harfbuzz inside his glyph rendering library, which is totally not where it should be used. ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] Thai Tam Shaping
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 that looks like a ] ) is moves all over the place. Harfbuzz is HEAD, with graphite2. Firefox is 41.0.2, with its own Harfbuzz. Here's the hb-shape: hb-shape --font-funcs=ft /Users/simon/Library/Fonts/NotoSansTaiTham-Regular.ttf [gid47=0+1812|gid70=0+1006|gid21=2+2236|gid70=2+1006|gid11=4+1220|gid69=4@-140,0+0|gid4=6@440,0+1896|gid57=6@-1920,0+484|gid39=8+1839|gid89=8@-559,0+0|gid135=8+1217|gid70=8+1006|gid135=8+1217|gid203=8+0|gid26=13+1130|gid70=13+1006] hb-shape --font-funcs=ft /Users/simon/Library/Fonts/lannaalif-v1-03.ttf [gid237=0+2107|gid260=0+958|gid211=2+2348|gid260=2+958|gid201=4+1240|gid259=4+0|gid99=6+2435|gid229=8+2184|three=8@-954,41+10|gid189=8+1200|gid260=8+958|gid189=8+1200|gid166=8+0|gid193=13+1319] [*] Since you probably can't see that, here's the Unicode decomposition: 1a4b 1a63 1a31 1a63 1a27 1a62 1a20 1a55 1a43 1a76 1a63 1a60 1a36 1a36 1a63 ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] Font substitution
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 ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Test please!
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, test.sil took 5.9s, Khaled's case took 60s. So no discernible advantage. Even removing the "obeylines" from Khaled's case and shipping the whole lot of Arabic to the shaper at once did not show much of a speed advantage either... ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Streamlining hb_font_t some more
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 shaping, then I agree that global font metric functions shouldn't be there. On the other hand, if Harfbuzz wants to be providing the information that layout engines need, then it absolutely should be able to tell you about global font metrics. But in that sense, the recent work on OT font functions isn't necessary either, because other libraries easily provide this. > If you only need a couple of fields it's easy to get them manually > from font blob. Eh, I don't know you about you but the reason I use libraries is to abstract away this kind of low-level grubbing around... But yeah, Freetype already does this. I just left it was a shame that something already had my font open and already had an OpenType parser ready to go, and it couldn't tell me what I wanted. ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Line spacing
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 to me is control and predictability — I > want to specify exactly where a line starts on a page (usually by > ascender/cap height), and then ensure that successive lines are > vertically aligned by baselines. So line spacing comes out of those > issues, not out of a somewhat arbitrary default. OK. Taking on board this and Khaled's post (and comments from Martin and others by mail) I have created a new SILE package. Loading linespacing allows you to choose between five line spacing methods: 1) the TeX algorithm. (In which case the package does nothing, because this is the default.) 2) Fixed baseline-to-baseline distance, using either an absolute value or a relative measurement (e.g. 1.2em) based on the current font. 3) Fit glyphs mode, where you specify the distance between the lowest bit of ink on the previous line and the highest bit of ink on the current line. 4) Fit font mode, where you specify the distance between the maximum global descender value of the fonts on the previous line (whether there are any descenders on that line or not) and the maximum global ascender value of the font on the current line (whether there are any ascenders on that line or not). 5) CSS mode, where half-leading is applied to the top and bottom of the line based on a linespace parameter. Hopefully between that lot, there should be enough control and predictability to do the intended thing with line spacing in whatever scripts you throw at SILE. S ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Streamlining hb_font_t some more
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 Harfbuzz will help me with at all. Behdad, how would your suggestion to use the font's typographic metrics work in practice? Do I need to go back to FT for this? Wasn't the whole point to get away from FT? S ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Streamlining hb_font_t some more
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 ascender/descender of the font and hence >> not >> need glyph bounding boxes in Sile at all. > > Yes please, an approach similar to what browsers do would be much > appreciated. TeX way of handling interline spacing has always been > cumbersome and confusing (not that I know exactly what SILE do now, but > the further from TeX way here the better). OK. SILE currently does the same as TeX, and I agree that it's confusing. I have just released SILE 0.9.3, so now I have a clean slate to play with. I have merged the new shaping pipeline (sending whole paragraphs to Harfbuzz) and moved over to HB OT functions, dropping the Freetype dependency. This makes a *lot* of things happier. Bidi support is much better, and it's now *much* faster too: my 28 page test document which used to take 15 seconds in 0.9.3 now takes 5 seconds. I'm happy to look at using the font ascender/descender metrics for line heights - is there a good way to get those values out of Harfbuzz yet? Grepping the repository doesn't turn up much. (There's also typographic line gap information in the _hea table - should I be using that?) Simon ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Streamlining hb_font_t some more
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 a question of priorities I would like to see more on getting the OT features complete and being able to drop FT support - so that means CFF and everything else. That's where the real speed increase is; if OT is not a complete replacement for FT, we can't use it yet, no matter how fast it is... S ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Kerning, glyph width, and x advance
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! ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Kerning, glyph width, and x advance
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 that's the same - it's the adjustment that I need to make to the "natural" glyph positioning done by the PDF. ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] Kerning, glyph width, and x advance
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 in the TJ array are the distances to go back after the glyph is painted. In other words, this is the unkerned X advance minus the kerned X advance. I had assumed that the unkerned glyph advance was the width of the character, but that's not the case: $ hb-shape --features='-kern' --show-extents /Library/Fonts/SuperClarendon.ttc 'VAV' [V=0+900<38,761,824,-761>|A=1+900<38,761,824,-761>|V=2+900<38,761,824,-761>] (This is not an OT/FT difference.) If I want to support OpenType kerning, and I need to compute the distance-to-go-back, do I really have to shape everything twice and then compare the x advances, or is there a smarter way to do it? ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] [PATCH] Add glyph extent information to hb-shape.
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, right? S ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] [PATCH] Add glyph extent information to hb-shape.
---
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 b/src/hb-buffer-serialize.cc
index 8a4..6a8509e 100644
--- a/src/hb-buffer-serialize.cc
+++ b/src/hb-buffer-serialize.cc
@@ -145,6 +145,16 @@ _hb_buffer_serialize_glyphs_json (hb_buffer_t *buffer,
pos[i].x_advance, pos[i].y_advance);
}
+if (flags HB_BUFFER_SERIALIZE_FLAG_SHOW_EXTENTS)
+{
+ hb_glyph_extents_t extents;
+ hb_font_get_glyph_extents(font, info[i].codepoint, extents);
+ p += MAX (0, snprintf (p, ARRAY_LENGTH (b) - (p - b),
,\xb\:%d,\yb\:%d,
+extents.x_bearing, extents.y_bearing));
+ p += MAX (0, snprintf (p, ARRAY_LENGTH (b) - (p - b),
,\w\:%d,\h\:%d,
+extents.width, extents.height));
+}
+
*p++ = '}';
unsigned int l = p - b;
@@ -210,6 +220,13 @@ _hb_buffer_serialize_glyphs_text (hb_buffer_t *buffer,
p += MAX (0, snprintf (p, ARRAY_LENGTH (b) - (p - b), ,%d,
pos[i].y_advance));
}
+if (flags HB_BUFFER_SERIALIZE_FLAG_SHOW_EXTENTS)
+{
+ hb_glyph_extents_t extents;
+ hb_font_get_glyph_extents(font, info[i].codepoint, extents);
+ p += MAX (0, snprintf (p, ARRAY_LENGTH (b) - (p - b), %d,%d,%d,%d,
extents.x_bearing, extents.y_bearing, extents.width, extents.height));
+}
+
unsigned int l = p - b;
if (buf_size l)
{
diff --git a/src/hb-buffer.h b/src/hb-buffer.h
index 4b285bb..622d112 100644
--- a/src/hb-buffer.h
+++ b/src/hb-buffer.h
@@ -323,7 +323,8 @@ typedef enum { /* flags */
HB_BUFFER_SERIALIZE_FLAG_DEFAULT = 0xu,
HB_BUFFER_SERIALIZE_FLAG_NO_CLUSTERS = 0x0001u,
HB_BUFFER_SERIALIZE_FLAG_NO_POSITIONS= 0x0002u,
- HB_BUFFER_SERIALIZE_FLAG_NO_GLYPH_NAMES = 0x0004u
+ HB_BUFFER_SERIALIZE_FLAG_NO_GLYPH_NAMES = 0x0004u,
+ HB_BUFFER_SERIALIZE_FLAG_SHOW_EXTENTS = 0x0008u
} hb_buffer_serialize_flags_t;
typedef enum {
diff --git a/util/hb-shape.cc b/util/hb-shape.cc
index f38f387..e7df07b 100644
--- a/util/hb-shape.cc
+++ b/util/hb-shape.cc
@@ -70,6 +70,8 @@ struct output_buffer_t
flags |= HB_BUFFER_SERIALIZE_FLAG_NO_CLUSTERS;
if (!format.show_positions)
flags |= HB_BUFFER_SERIALIZE_FLAG_NO_POSITIONS;
+if (format.show_extents)
+ flags |= HB_BUFFER_SERIALIZE_FLAG_SHOW_EXTENTS;
format_flags = (hb_buffer_serialize_flags_t) flags;
}
void new_line (void)
diff --git a/util/options.cc b/util/options.cc
index 0821a17..743b91b 100644
--- a/util/options.cc
+++ b/util/options.cc
@@ -706,6 +706,8 @@ format_options_t::add_options (option_parser_t *parser)
G_OPTION_ARG_NONE,this-show_positions,
Do not output glyph positions,
NULL},
{no-clusters,0, G_OPTION_FLAG_REVERSE,
G_OPTION_ARG_NONE,this-show_clusters,
Do not output cluster indices,
NULL},
+{show-extents, 0, 0,
+G_OPTION_ARG_NONE, this-show_extents, Show glyph extents,
NULL},
{NULL}
};
parser-add_group (entries,
diff --git a/util/options.hh b/util/options.hh
index 6eb6c04..f1ec8cf 100644
--- a/util/options.hh
+++ b/util/options.hh
@@ -410,6 +410,7 @@ struct format_options_t : option_group_t
show_text = false;
show_unicode = false;
show_line_num = false;
+show_extents = false;
add_options (parser);
}
@@ -450,6 +451,7 @@ struct format_options_t : option_group_t
hb_bool_t show_text;
hb_bool_t show_unicode;
hb_bool_t show_line_num;
+ hb_bool_t show_extents;
};
--
2.2.1
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] Inconsistent shaping across systems
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 ~/.fonts/NotoSansCJKjp-Light.otf '世界' [gid9861=0@-500,-880+0,-1000|gid27506=1@-500,-880+0,-1000] and OS X (not using CoreText) gives $ md5sum ~/Library/Fonts/NotoSansCJKjp-Light.otf f269c193b1ef0b739030d56386670c3f ~/Library/Fonts/NotoSansCJKjp-Light.otf $ hb-shape --direction=ttb ~/Library/Fonts/NotoSansCJKjp-Light.otf '世界' [gid9861=0@-500,-894+0,-1000|gid27506=1@-500,-894+0,-1000] ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Zero-width joiner has width
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 probably want to shape text at the
upem size to have on precision loss whatsoever.
OK, I'm now trying to set the scaling to the font upem, but I'm not
getting that working either. Assuming an incoming FT_Face face:
hb_ft_font = hb_ft_font_create(face, NULL);
hb_face_t* hbFace = hb_font_get_face(hb_ft_font);
/* Attempt to set upem scale */
unsigned int upem = hb_face_get_upem(hbFace);
hb_font_set_scale(hb_ft_font, upem, upem);
printf(upem = %i\n, upem);
This prints upem = 2048; so far so good. Now after shaping:
...
shape_plan = hb_shape_plan_create_cached(hbFace, segment_props,
features, nFeatures, NULL);
int res = hb_shape_plan_execute(shape_plan, hb_ft_font, buf,
features, nFeatures);
glyph_info = hb_buffer_get_glyph_infos(buf, glyph_count);
glyph_pos= hb_buffer_get_glyph_positions(buf, glyph_count);
...
lua_pushstring(L, x_advance);
lua_pushnumber(L, glyph_pos[j].x_advance);
lua_settable(L, -3);
...
{
{
codepoint = 77,
depth = 0,
height = 4.6875,
name = m,
x_advance = 514,
},
}
Should be 1645, right? I am not sure where 514 is coming from.
The full shaper code is at
https://github.com/simoncozens/sile/blob/master/src/justenoughharfbuzz.c#L292
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Zero-width joiner has width
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); unsigned int upem = hb_face_get_upem(hbFace); hb_font_set_scale(hb_ft_font, upem, upem); hb_ft_font_set_funcs(hb_ft_font); It's about 50% slower than using Freetype functions directly, which is a big shame(!), but computers always get faster and I'm sure this way gives me more flexibility later... See latest version: https://github.com/simoncozens/sile/blob/master/src/justenoughharfbuzz.c#L263 ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Zero-width joiner has width
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 from xetex. :-) ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Question about shaping with top to bottom direction
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 Japanese full-width numberic glyphs (２０１５). There are multiple ways to arrange Latin text within Japanese vertical texts; rotating the glyphs is one way, another way is to use fixed-width full-width characters in horizontal orientation, and tate-chu-yoko is another one. See http://www.w3.org/TR/jlreq/#fig1_19-en Because there are multiple ways to do this, Harfbuzz isn't going to choose between them for you. You have to do that. And Japanese fonts generally don't contain rotated forms of Latin glyphs, whereas Harfbuzz's job is just to go from Unicode text to the glyphs that are in your font, so it can't really help you in this case. If you want to rotate the Latin text, you need to do it yourself. Simon ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] Vertical Mongolian
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 the joining
characters:
text = ᠲᠣᠣᠷ
SILE.shaper:shapeToken(text, SILE.font.loadDefaults({ font =
Mongolian White, direction = LTR }))
{
{
codepoint = 589,
depth = -1.2744140625,
height = 6.1181640625,
name = uni1832.E914_t.init,
width = 4.8828125,
},
{
codepoint = 373,
depth = -0.8447265625,
height = 4.39453125,
name = uni1823.E83C_o.medi,
width = 2.9296875,
},
{
codepoint = 373,
depth = -0.8447265625,
height = 4.39453125,
name = uni1823.E83C_o.medi,
width = 2.9296875,
},
{
codepoint = 618,
depth = -0.4052734375,
height = 6.73828125,
name = uni1837.E931_r.fina,
width = 3.41796875,
},
}
When I shape the text with direction set to TTB, then I get *isolated*
forms:
{
{
codepoint = 274,
depth = 0,
height = 9.08203125,
name = uni1832.t,
width = 4.8828125,
},
{
codepoint = 259,
depth = 0,
height = 9.08203125,
name = uni1823.o,
width = 6.103515625,
},
{
codepoint = 259,
depth = 0,
height = 9.08203125,
name = uni1823.o,
width = 6.103515625,
},
{
codepoint = 279,
depth = 0,
height = 9.08203125,
name = uni1837.r,
width = 3.1689453125,
},
}
Obviously what I would like to get is vertical positioning of joined-up
Mongolian. I could set the direction to LTR and then rotate everything,
but that feels like a hack. I'm typesetting TTB, so the direction should
be TTB.
Noto Sans Mongolian also shows the same behaviour. Is this expected?
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] Problems with TTB Japanese
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 Gothic, direction = TTB })
SILE.shaper:shapeToken(a, SILE.font.loadDefaults({}))
{
{
codepoint = 68,
depth = -0.078125,
height = 5.4296875,
name = ,
width = 5,
x_offset = -2,
y_offset = -8,
},
{
codepoint = 2102,
depth = 0.8984375,
height = 8.0859375,
name = ,
width = 10,
x_offset = -5,
y_offset = -8,
},
}
This happens for all fonts. I don't know why a fairly normal Japanese
character would be set downwards and to the left; it's causing things
not to line up to the kihonhanmen (character grid). Am I right in
thinking the idea is to cause Japanese and non-Japanese characters to be
aligned on the center axis?
The other problem I just solved by talking to the rubber duck.
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Problems with TTB Japanese
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 a top-center origin.
What font funcs are you using?
This may be the problem. I'm using hb_ft_font_create, getting the glyph
information and positions. I use x_offset and y_offset from
hb_buffer_get_glyph_positions to alter the cursor position. (because
otherwise Arabic doesn't work), and then use a function like this to
get the metrics to put the glyph in a (TeX-like) box:
(Following code mostly stolen from XeTeX, with the TTB special case
added yesterday after talking to the rubber duck.)
void calculate_extents(box* b, hb_glyph_info_t glyph_info,
hb_glyph_position_t glyph_pos, FT_Face ft_face, double point_size,
hb_direction_t direction) {
FT_Error error = FT_Load_Glyph(ft_face, glyph_info.codepoint,
FT_LOAD_NO_SCALE);
if (error) return;
FT_Glyph glyph;
error = FT_Get_Glyph(ft_face-glyph, glyph);
if (error) return;
FT_BBox ft_bbox;
FT_Glyph_Get_CBox(glyph, FT_GLYPH_BBOX_UNSCALED, ft_bbox);
FT_Fixed advance;
FT_Get_Advance(ft_face, glyph_info.codepoint, FT_LOAD_NO_SCALE, advance);
const FT_Glyph_Metrics *ftmetrics = ft_face-glyph-metrics;
b-width = advance * point_size / ft_face-units_per_EM;
if (direction == HB_DIRECTION_TTB) {
FT_Get_Advance(ft_face, glyph_info.codepoint, FT_LOAD_NO_SCALE |
FT_LOAD_VERTICAL_LAYOUT, advance);
b-height = advance * point_size / ft_face-units_per_EM;
b-depth = 0;
} else {
b-height = ft_bbox.yMax * point_size / ft_face-units_per_EM;
b-depth = -ft_bbox.yMin * point_size / ft_face-units_per_EM;
}
FT_Done_Glyph(glyph);
}
I don't see a way to tell hb-ft that the font is going to be used with
vertical baselines.
S
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Unsure how to use HB output to combine characters
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 possibly FT) is not telling me the truth about how to position my glyphs. What am I doing wrong? Allowing the PDF viewer to do shaping? So I *shouldn't* be getting two glyphs out of Harfbuzz. If I run hb-shape using the Jomolhari Tibetan font, it gives me one glyph. Aha! Looking at the Kokonor font repertoire in Font Book, it *does* have the SA/KA combination sitting right there in glyph position 318. Harfbuzz should surely be returning that to me. The other Tibetan font that comes with OS X, Kailasa, has a SA/KA combination but I still get two separate glyphs out of Harfbuzz. OS X's own font shaper *can* render Tibetan stacks properly in both Kokonor and Kailasa, as the text works fine in the browser / text editor / etc. That information must be there in the font to render the stacks correctly, but Harfbuzz is not correctly picking it up. On the page http://digitaltibetan.org/index.php/Tibetan_Fonts#Mac_OS-X_Unicode_fonts , it says Unfortunately both Mac OS-X 10.5 and 10.6 (which supports Tibetan) and Adobe's programs support a different set of OpenType features which are required to correctly render Tibetan glyphs. So far Chris Fynn's Jomolhari ID font is the only publicly available font that supports all platforms. Are funny OpenType tables in use? I'm shocked; it looks like this might not actually be my fault at all. ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] Unsure how to use HB output to combine characters
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 two glyph
values, 118 and 160:
1: (སྐ)
1: U+0F66,U+0F90
1: [118=0+1539|160=0+0]
The glyph_pos structures (using a scaled font via hb_ft_font_create) for
each glyph look like this:
{ x_advance = 375, y_advance = 0, x_offset = 0, y_offset = 0 }
{ x_advance = 0, y_advance = 0, x_offset = 0, y_offset = 0 }
That all seems fine, I think. (I'm confused why I should be advancing
after the first glyph and then not after the combining character, but I
don't think that's actually the problem here.)
Next I output that glyph string in my PDF document, where it looks like
Td[007600a0]TJ. (I have been spending too much time reading PDF
documents in a text editor this week.)
What I see in my output is two separate glyphs next to each other, ས
(TIBETAN LETTER SA U+0F66) and ྐ (TIBETAN SUBJOINED LETTER KA U+0F90)
with the hello I am a combining character dotted circle around it.
Shouldn't the combination be its own glyph in the font? How do I say in
PDF-speak combine these two glyphs together, or should the font be
doing that for me?
I think the font supports combining these two characters, as it seems to
look fine in a text editor. My code can render Latin combining sequences
correctly, and Arabic works as well. I don't understand why Tibetan
subjoined characters aren't playing for me.
What am I doing wrong?
Simon
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Inter-glyph spacing
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 graphite integration bug? At my current stage of playing with font rendering, it's far more likely the problem is in my code and not in someone else's! I'm not sure it's a Graphite bug because non-graphite OpenType fonts are being weird too... In fact, trying with a bunch more fonts, OpenType would be the common denominator here. All OpenType fonts are showing too little spacing between /most/ letters. (some are correct) Times, Rosetta and other Truetype fonts are fine. Deeper and deeper. Simon ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
Re: [HarfBuzz] Inter-glyph spacing
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 that the FC_SLANT pattern was not being added in cases where f-slant is zero, which is unfortunately FC_SLANT_ROMAN. Doubly unfortunately, fontconfig can sometimes choose an italic font by default if you don't explicitly specify a slant. So I was rendering a Roman font with spacing that Harfbuzz correctly computed for an italic font. Hence the strange spacing problems. Sorry! Harfbuzz works perfectly now I've removed that. For what it's worth, I've written up what I've learnt at http://www.simon-cozens.org/content/duffers-guide-fontconfig-and-harfbuzz ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
[HarfBuzz] Inter-glyph spacing
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 (FT_New_Face(uds-ft_library, font_path, 0, (uds-ft_face))) return 0; if (FT_Set_Char_Size(uds-ft_face,f-pointSize * 64.0, 0, 0, 0)) return 0; And then (largely copied from the SDL example) hb_ft_font = hb_ft_font_create(uds-ft_face, NULL); buf = hb_buffer_create(); if (f-script) hb_buffer_set_script(buf, hb_tag_from_string(f-script, strlen(f-script))); if (f-direction) hb_buffer_set_direction(buf, f-direction); if (f-lang) hb_buffer_set_language(buf, hb_language_from_string(f-lang,strlen(f-lang))); /* Layout the text */ hb_buffer_add_utf8(buf, text, strlen(text), 0, strlen(text)); hb_shape(hb_ft_font, buf, NULL, 0); And then when rendering, I move the rendering pen forward by glyph_pos.x_advance/64.0 points after displaying each glyph. Is this the right way to handle the result of hb_buffer_get_glyph_positions? (I know I have to also handle x_offset but the x_offsets are all zero in this example.) What also confuses me is that the result is very font-specific. SIL fonts are squashed. Times and Optima render perfectly: Pango and Harfbuzz equivalent. Adobe Garamond Pro and Caslon Pro are horrible, with some very strange inter-glyph spacing; in particular there is too much space after every letter a, and too little after an s. I've attached a comparison of the Pango and Harfbuzz outputs. Any help would be appreciated. Thanks! Simon shapers.pdf Description: Adobe PDF document ___ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
