[util] Add hb-view --ink-box to take text ink bounding box for image size?

[twardoch]

+1

[davelab6]

+1

[behdad]

Any other small requests? File issues, I'm on a roll right now. :D

[twardoch]

Not sure how small it is, but — as you already know — I'd be all in favor of allowing the user to disable the "convenience functionalities" such as the fallback Arabic shaping (and the others you've listed). That, to me, is the most important semi-small thing that I'd love to have (and, I think, others would benefit from as well). I've added https://github.com/behdad/harfbuzz/issues/80 for that.

[HinTak]

I was looking for similar bugs before I file a new one: am doing some illustrations for my LG talk and found the padding around hb-view to be uneven - I have worked out that it seems to start at (16,16), and it seems to do 16 pixels on either side horizonally, but the bottom padding seems to vary from anthying from 16 to 22, etc... what exactly does it do for bottom padding?

[HinTak]

At 256pt, the bottom padding goes up to 67pt. (while the other 3 sides stay at 16 pt).

[behdad]

At 256pt, the bottom padding goes up to 67pt. (while the other 3 sides stay at 16 pt).

You're seeing the font's descender, which happens to be left blank in your example. ink-box will definitely help with that.

[behdad]

You can set padding separately for the four sides, including negative padding.

[HinTak]

Argh, the bottom must be reserved space for --annotate, which I did not use.

[HinTak]

It seems that I want --margin=0, and removing the space allocated for --annotate.

[behdad]

Humm. I don't think we allocate space for annotate, no.

On Thu, Apr 7, 2016 at 5:54 PM, HinTak notifications@github.com wrote:

It seems that I want --margin=0, and removing the space allocated for --annotate.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/behdad/harfbuzz/issues/79#issuecomment-207153085

behdad http://behdad.org/

[HinTak]

Argh, thanks. That explains it - CJK fonts do have Latin glyphs and non-zero descenders, but obviously I am not using Latin glyphs and keep forgetting that they are there, and just keep seeing empty spaces below :-).

[HinTak]

I suppose if the code accepts negative margins, and there is a way of calculating and displaying the bound box vs the ascender/descender, that would be a first step...

[HinTak]

It is also perhaps slightly confusing at the moment that ansi output does --ink-box effectively, but all of the others don't.

[HinTak]

hb-shape has a --show-extents option which effectively gives you the size and position of the ink-box for each of the glyphs. Duplicating /invoking some of the same logic into hb-view , to use the largest of y_max and lowest of y_min of the collection of glyphs instead of the font's ascender/descender should do it. (plus setting X margin to zero).

For vertical layout, swap the treatment of x and y... The X equivalent of descender is probably just zero?

[HinTak]

Besides many devanagari fonts have big ascender/descender (and big empty space above/below), I found an opposite case: a font drawing outside the region calculated by the current hb-view code.

If you draw the Persian word for harfbuzz in Arabic with the farsi font from the arabeyes project, the left side of the image is clipped. This is because hb-view does not know that the left most glyph has a negative x bearing.

Anyway, I have decided that for something like this (visual / user-friendly options / mandate stuff of calculating the smallest box that would contain all the ink ), I don't want to do c++. So I have started re-implementing part of hb-shape/hb-view in python using harfbuzz's gobject introspection binding. I should have something to show soon.

[HinTak]

I have extended the gobject python example to print the 4 margin values to crop to ink box ( https://github.com/HinTak/harfbuzz/commit/667ddae3081b49fb6d25427bd45f781ac9c064de ) . Passing the 4 numbers printed at the end to hb-view give you the tight ink-box look. Tested mostly with Arabic.

Please feel free to copy the python code logic back to the c++ utility.

If I find enough time, I'll append cairo drawing code (pycairo) to the end of the script to draw it...

[HinTak]

I have re-cycled some old python code I wrote for freetype-py to do the drawing with cairo. So here it is:

https://github.com/harfbuzz/harfbuzz/commit/70a81d053af7791cd58beb64eca8d32227371a15

What the c++ hb-view does (reversed background/forreground, but otherwise at default):

What my new python code does:

heehee.

I feel like putting this into a harfbuzz-python-demos project. cc @anthrotype - please feel free to rewrite the first half in uharfbuzz.... then we can definitely have a harfbuzz-python-demo project pitching different harfbuzz python bindings...

[HinTak]

another comparison - current upstream:

the python code:

[HinTak]

I have tidied and put the code up ( https://github.com/HinTak/harfbuzz-python-demos ) as well as wrote a readme with the images above, explaining what it does.

@anthrotype : please feel free to improve and/or port it to uharfbuzz .

[behdad]

Can we get you to move your chatter somewhere else? We all know what limitations of logical vs ink box are, and how to implement it. Don't need to see how you did it. Thank you.

[HinTak]

Okay. People who end up here can go file issues, add code at https://github.com/HinTak/harfbuzz-python-demos , or copy the 20 to 30 lines of python code back to c++ here.