[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
>