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. > > 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? > > 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. > 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. Yours, Martin _______________________________________________ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
