[HarfBuzz] hb-view

[Behdad Esfahbod]

On 03/30/11 13:43, Adam Twardoch (List) wrote:
> 
> I think it's safe to assume that hb-view (at least from commandline)
> should act *as if there is only ONE glyph run*, i.e. there is ONE font +
> directionality + script + language + set of features. Just ONE (declared
> externally, using the commandline parameters -- so there should be a
> commandline switch to declare --direction).

Right.  But sometimes it's useful to test turning a feature on for one
character only.  Note that such changes do not break shaping runs.

Other than that, yes, there is --script, --language, and --direction alreay.


> This is the most basic case, and very common. Also, by doing this, you
> allow testing to focus on Harfbuzz itself.
> 
> The only one interesting addition would be an option to output not the
> PNG but instead it would output to stdout a simple string in the form of
> something like:
> 
> ((gid,x,y),(gid,x,y),(gid,x,y))
> 
> That is, the glyph ID, the x offset and the y offset for each glyph.
> Nothing fancier. This could be fed into any other custom rasterizing
> service that could do the imaging. Of course, the actual syntax could be
> Json, XML or something like that.

You're reading my mind :).  That's exactly what I'm doing in the test suite
I'm hacking on right now.


> If you're going to support some more complex markup on input, with mixed
> directionality, mixed feature sets etc., this means you'd be doing
> multiple glyph runs. Then you need to pull in FriBidi, XML input markup,
> also some more refined output markup probably etc. This would still be
> working within one line, I assume, but would be potentially be more
> dependant on other libs. In such case, perhaps even multiple fonts,
> multiple sizes? :)

I'm happy to keep hb-view as a test tool, and advocate people to use
pango-view for the more complex cases.  As far as testing harfbuzz goes,
multiple fonts, multiple sizes, etc are not interesting.  However, sub-run
features are, because that's what hb_shape() accepts.


> In such case, I'd propose to make this other thing into a second tool
> (something like hb-layout). Please keep hb-view simple -- one glyph run
> only, and minimal dependancy on other libraries! (Right now it's glib,
> cairo and libpng, and I'd like to keep it that way). This way, the
> hb-view code can also be a MINIMAL EXAMPLE for coding (in fact, I just
> showed hb-view.c to one of our developers, and he finally understood how
> it works).

I agree.


> Then, hb-layout could be the more advanced thing, but this really sounds
> like a somewhat separate project. Please keep hb-view simple, and if you
> want, make another tool hb-layout that does more fancy stuff. :)

Yes, forget about hb-layout.  It's called pango-view already :).

behdad

> Best,
> Adam
>