Re: [HarfBuzz] A plea to make HarfBuzz easier to build.

[Daniel Ribeiro Maciel]

Hi Behdad,

I wrote this hb.cc file. Drop it in the root of harfbuzz source tree to try
it out. You will need to add both Freetype and 'hb-ucdn' to the include
path though.

It will *not* compile; there are a bunch of symbol redefinition problems
and other seemingly (?) trivial things to fix (82 issues to be exact).
I did not apply any patches to harfbuzz source tree itself. Thought you
might want to change those things yourself since they would take some
renaming of enum variables and other stuff.

Let me know if you want a patch for that as well, I believe I'm able to
write it myself.

Cheers,
Daniel



On Wed, Dec 30, 2015 at 2:21 PM, Behdad Esfahbod 
wrote:

> Thanks Daniel.  I'm not opposed to the idea if it doesn't introduce too
> many
> hacks.  Might take a look at it myself even.
>
> On 15-12-28 11:00 PM, Daniel Ribeiro Maciel wrote:
> > I can write a '.cc' file which includes all other '.cc' files and
> defines a
> > bunch of stuff if you guys are willing to add such file to your source
> tree.
> >
> > On Tue, Dec 15, 2015 at 11:14 AM, Jonathan Blow  > > wrote:
> >
> > Sure, it would be fine to add this; there is also a for-loop in one
> spot
> > that doesn't compile in Visual Studio because it declares an enum
> inline,
> > so one has to move the enum.
> >
> > But these things don't matter, they only take a minute to fix. It's
> > trivial. Whereas getting the library to build and link for the first
> time
> > is measured in hours.
> >
> > It is a two-orders-of-magnitude difference, which is why I am saying
> that
> > if widespread use of the code is a goal, making it easier to build
> should
> > be the priority.
> >
> > On Tuesday, December 15, 2015, Behdad Esfahbod <
> behdad.esfah...@gmail.com
> > > wrote:
> >
> > On 15-12-13 09:33 PM, Jamie Dale wrote:
> > > You'll need a define to stub out getenv for a PS4 build
> >
> > I'll take a patch to hb-private.hh to do that.
> >
> >
> > ___
> > HarfBuzz mailing list
> > HarfBuzz@lists.freedesktop.org  HarfBuzz@lists.freedesktop.org>
> > http://lists.freedesktop.org/mailman/listinfo/harfbuzz
> >
> >
>

#define HAVE_FREETYPE
#define HAVE_OT
#define HAVE_UCDN
#define HAVE_INTEL_ATOMIC_PRIMITIVES

#include "src/hb-blob.cc"
#include "src/hb-buffer-serialize.cc"
#include "src/hb-buffer.cc"
#include "src/hb-common.cc"
#include "src/hb-face.cc"
#include "src/hb-font.cc"
#include "src/hb-ot-tag.cc"
#include "src/hb-set.cc"
#include "src/hb-shape.cc"
#include "src/hb-shape-plan.cc"
#include "src/hb-shaper.cc"
#include "src/hb-unicode.cc"
#include "src/hb-warning.cc"

// OT Sources

#include "src/hb-ot-font.cc"
#include "src/hb-ot-layout.cc"
#include "src/hb-ot-map.cc"
#include "src/hb-ot-shape.cc"
#include "src/hb-ot-shape-complex-arabic.cc"
#include "src/hb-ot-shape-complex-default.cc"
#include "src/hb-ot-shape-complex-hangul.cc"
#include "src/hb-ot-shape-complex-hebrew.cc"
#include "src/hb-ot-shape-complex-indic.cc"
#include "src/hb-ot-shape-complex-indic-table.cc"
#include "src/hb-ot-shape-complex-myanmar.cc"
#include "src/hb-ot-shape-complex-thai.cc"
#include "src/hb-ot-shape-complex-tibetan.cc"
#include "src/hb-ot-shape-complex-use.cc"
#include "src/hb-ot-shape-complex-use-table.cc"
#include "src/hb-ot-shape-normalize.cc"
#include "src/hb-ot-shape-fallback.cc"

// UCDN Sources

#include "src/hb-ucdn.cc"
#include "src/hb-ucdn/ucdn.c"

// Freetype Sources

#include "src/hb-ft.cc"
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] Beginner question: What are cluster levels?

[Jamie Dale]

I actually just wrote something to give me very similar information since I
realised that my basic "this is a ligature" flag wasn't enough data, so
each of my glyphs now contains the number of characters that the glyph was
composed from. This, along with the cluster index of the glyph from the
source text, and the reading direction of the glyph, allow me to work out
which characters formed the glyph.

-Jamie.
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] Beginner question: What are cluster levels?

[Graham Douglas]

On 04/01/2016 17:06, Behdad Esfahbod wrote:
> Hi Jamie and Deepak,
>
> I'll try to get a detailed reply to this thread tomorrow.
>
> Cheers,
> behdad
>
> 
> ___
> HarfBuzz mailing list
> HarfBuzz@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Hi Behdad

I too am interested in this. In particular, suppose you have a shaped
glyph,
---such as an Arabic ligature--- I'd like to know if it is possible to
determine
the set of (unshaped) input characters (glyphs) from which the ligature was
constructed. I'm not doing hit testing, just PDF generation (via LuaTeX
--- and libraqm).
I just want typeset things like this:

LIGATURE <--- ...+U2+U1

where Ui are the constituent unshaped Arabic glyphs
which have been combined to create the LIGATURE.

Cheers
Graham
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] Beginner question: What are cluster levels?

[Jamie Dale]

Thanks, I also have another question related to what I mentioned yesterday:
Is there a reliable way to detect which glyphs are ligatures?

My current solution checks for gaps in the cluster indices of the shaped
glyph infos, but that also requires some special case handling to detect if
the last glyph in a sequence is a ligature. I was hoping
hb_glyph_info_t::mask might specify this, but as far as I can tell, it's
always set to 1 (I'm using version 1.0.5).

-Jamie.
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master'

[Behdad Esfahbod]

On 16-01-04 02:33 AM, Martin Hosken wrote:
> Dear Behdad,
> 
>>> So, I would add an enum to the debug message to give a debug message event 
>>> type.
>>
>> My current thinking is that everything is transferred as a text API in
>> one-line messages.  The client can transform that to an enum if desired.
> 
> That works only if the messages are constrained to be parsable. In effect the 
> string is being used as a way of passing an identifier and varargs. To make 
> life easy for the poor debugger, the messages should be structured in a way 
> that makes them parsable without knowing the context of the message.

You can think of it that way.  The nice thing about a message API is that it
will be trivial to pass the info to another process, or just write it to a file.


>>> One big question that always needs to be answered in the debugger is: where 
>>> are we? Where in the buffer are we now processing. This is the idx field of 
>>> the buffer. I don't think this is exposed in the public buffer interface. 
>>> So it either needs to be exposed or passed as part of the debug message.
>>
>> I'm unsure about this one.  We don't expose the out_buf pard of the buffer, 
>> so
>> calling client code in the middle of a pass of transformation is harmful
>> currently.  Exposing all of that, on the other hand, leaks a lot of the 
>> buffer
>> design, which I like to avoid right now.  Indeed, we might end up changing 
>> the
>> buffer internals to accommodate the lookup direction proposal.
>>
>> So, for now, no callbacks in the middle of a pass.  I understand that's far
>> from ideal, but at least we are now answering the big question: which lookup
>> did what.
> 
> It doesn't answer: which lookup did what *where*. It's the "where" I am 
> trying to answer. If you get given the buffer before the change and after, 
> it's asking a lot of the debugger to work out precisely where the change 
> occurred. Can we, therefore, please pass idx as part of the debug message?

As I tried to explain, we can't make a callback in the middle of the run.
Indeed.  Maybe you can explain or show screenshots or screenshoots of what
kind of debugger you have in mind.  You have one for Graphite, right?  I
wanted to get a live demo from you at the OpenType meeting, but we forgot.

For me, I've imagined that mostly the consumer of this is a human reading the
messages, not a GUI debugger per se...


>>> For GPOS we need to be passing parameters like the two points in an 
>>> attachment or the actual calculated offset in a pair or single adjustment. 
>>> When doing classed based activities, we should be passing the class values 
>>> involved or perhaps pointers (or offsets) to the data structures involved 
>>> so that a debugger can turn cross reference that back to source code.
>>
>> GPOS is more friendly since the buffer structure is fully exposed.  Though,
>> deferred attachments won't be exposed.
> 
> But even with the buffer, you don't know which AP was used and what the 
> relative positions were of the APs.

We are *not* going to expose the entire GSUB/GPOS details in any API.


>> I'm probably going to add shape_plan to list of arguments.  After that, if I
>> make a release, the API is here to stay...  So, speak very loudly if you 
>> think
>> for whatever reason this is not workable.  Ie, there are things that cannot 
>> be
>> done using a message.  I can't think of any.
> 
> Bear in mind that the structure of the message, at least at a high level, is 
> part of that API.

Yes, indeed.  And we need to document it.

As mentioned before, I even support a harfbuzz-support.so or
harfbuzz-debugger.so that parses the message into the kind of API you want.  I
just don't want to put that in harfbuzz.so.  However, I first want to see what
kind of uses you have in mind with that data.

Cheers,
b

> Yours,
> Martin
> 
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] HarfBuzz glyph offsets

[Behdad Esfahbod]

Thanks Daniel.  Fixed in master.  I'll get a release out today or tomorrow.

behdad

On 16-01-04 09:31 PM, Daniel Ribeiro Maciel wrote:
> Attached the x_advance and x_offset of each codepoint.
> Also, attached the screenshots of each version.
> 
> Thanks,
> Daniel
> 
> On Mon, Jan 4, 2016 at 3:09 PM, Daniel Ribeiro Maciel  > wrote:
> 
> Yes, will do it in about 4h-5h as I'm currently unable to access my dev
> station.
> 
> Thanks Behdad.
> 
> On Mon, Jan 4, 2016 at 2:25 PM, Behdad Esfahbod  > wrote:
> 
> Hi Daniel,
> 
> Can you attach hb-shape output of the old and new HarfBuzz?
> 
> Thanks,
> behdad
> 
> On 16-01-04 04:15 PM, Daniel Ribeiro Maciel wrote:
> > Test string: "T. W. AV Ve"
> > Font used Garamond Premier Pro, attached here.
> >
> > I use xAdvance for offsetting glyphs and FreeType to render.
> > I will generate some PNGs and send them to you guys as well.
> >
> > Thanks!
> > Daniel
> >
> > On Mon, Jan 4, 2016 at 9:54 AM, Behdad Esfahbod 
> mailto:behdad.esfah...@gmail.com>
> >  >> wrote:
> >
> > Hi Daniel,
> >
> > We need to see a sample font and string to be able to help.
> >
> > behdad
> >
> > On 16-01-04 02:37 AM, Daniel Ribeiro Maciel wrote:
> > > Hi Behdad,
> > >
> > > I have a testsuite for my font stuff. After upgrading from 
> 1.0.6 to 1.1.0
> > > (narrowed it down), kerning is no longer enabled. (My kerning 
> test suite fails
> > > horribly, no kerning is applied at all)
> > >
> > > One notable thing is I'm currently using my own 
> CMakeLists.txt file to build
> > > and link to harfbuzz.
> > >
> > > Maybe now I need to define something extra to enable kerning 
> again?
> > >
> > > Any clues on what might be going on there?
> > >
> > > Cheers,
> > > Daniel
> > >
> > > On Mon, Dec 28, 2015 at 8:32 PM, Khaled Hosny 
> mailto:khaledho...@eglug.org>
> >
> > > 
>  > >
> > > That was because of the new HB_EXTERN decorator, fixed in:
> > > https://github.com/behdad/harfbuzz/pull/202
> > >
> > > Regards,
> > > Khaled
> > >
> > > On Sat, Dec 26, 2015 at 03:25:29AM +0400, Khaled Hosny 
> wrote:
> > > > I just noticed now that almost all functions are missing
> from the
> > > > generated documentation. When I run the build locally I
> see lots of:
> > > >
> > > >./harfbuzz-sections.txt:422: warning: No declaration
> found for
> > > hb_feature_to_string.
> > > >
> > > > which would explain why they are missing from the docs,
> but I couldn’t
> > > > manage to find why it can’t find them with my limited
> understanding of
> > > > gtk-doc.
> > > >
> > > > On Fri, Dec 25, 2015 at 06:46:22PM +0100, Behdad
> Esfahbod wrote:
> > > > > This is all live now:
> > > > > http://behdad.github.io/harfbuzz/
> > > > >
> > > > >
> > > > > On 15-12-24 04:32 AM, Simon Cozens wrote:
> > > > > > 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...)
> > > > > >
> 

[HarfBuzz] harfbuzz: Branch 'master' - 2 commits

[Behdad Esfahbod]

 src/hb-open-type-private.hh|2 +-
 src/hb-ot-layout-common-private.hh |3 +++
 2 files changed, 4 insertions(+), 1 deletion(-)

New commits:
commit 53c47c85827a7e3ca82000e3baa9aa87c5770ce9
Author: Behdad Esfahbod 
Date:   Tue Jan 5 13:26:20 2016 +

Increase sanitize edit count from 8 to 32

See previous commit.

diff --git a/src/hb-open-type-private.hh b/src/hb-open-type-private.hh
index 1e40378..6323da8 100644
--- a/src/hb-open-type-private.hh
+++ b/src/hb-open-type-private.hh
@@ -182,7 +182,7 @@ struct hb_dispatch_context_t
 
 /* This limits sanitizing time on really broken fonts. */
 #ifndef HB_SANITIZE_MAX_EDITS
-#define HB_SANITIZE_MAX_EDITS 8
+#define HB_SANITIZE_MAX_EDITS 32
 #endif
 
 struct hb_sanitize_context_t :
commit da2fcfdc51a2cc0d0a782efa6c91b733f7aa84ba
Author: Behdad Esfahbod 
Date:   Tue Jan 5 13:23:45 2016 +

Don't count fixing-up FeatureParams offset as error

The font Garamond Premier Pro Caption (and possibly many other
Adobe fonts), have many FeatureParamsSize tables with the old
wrong offset.  We handle fixing those up, but they were still
contributing to edit_count, and when I reduced HB_SANITIZE_MAX_EDIT
from 100 to 8 in 14c2de321826c36037adde859ccca3e2011325a9, these
fonts were now getting GPOS dropped and hence kerning disabled.

Fix, by not counting edits made towareds offset fix-up.  I'll
also increase edit count again, in the next commit.

diff --git a/src/hb-ot-layout-common-private.hh 
b/src/hb-ot-layout-common-private.hh
index 5b21f14..64829ac 100644
--- a/src/hb-ot-layout-common-private.hh
+++ b/src/hb-ot-layout-common-private.hh
@@ -545,6 +545,9 @@ struct Feature
  c->try_set (&featureParams, new_offset) &&
  !featureParams.sanitize (c, this, closure ? closure->tag : 
HB_TAG_NONE))
return_trace (false);
+
+  if (c->edit_count > 1)
+c->edit_count--; /* This was a "legitimate" edit; don't contribute to 
error count. */
 }
 
 return_trace (true);
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz