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 > _______________________________________________ HarfBuzz mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/harfbuzz
