Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support unclipped viewbox for bitmap formats #402

Open
anthrotype opened this issue Apr 4, 2022 · 4 comments
Open

Support unclipped viewbox for bitmap formats #402

anthrotype opened this issue Apr 4, 2022 · 4 comments

Comments

@anthrotype
Copy link
Member

Currently, it's impossible to produce a bitmap color font (CBDT or sbix) containing color glyphs that "kern" over the next or preceding one, or that stretch beyond the ascender/descender lines.
E.g. take this test file 0053.svg and compile to CBDT. Notice how the --noclip_to_viewbox is essentially ignored:

$ nanoemoji --noclip_to_viewbox --color_format cbdt 0053.svg 

Screen Shot 2022-04-04 at 15 27 02

The expected result should look like the COLRv1 version (OT-SVG also works):

$ nanoemoji --noclip_to_viewbox --color_format glyf_colr_1 0053.svg

Screen Shot 2022-04-04 at 15 26 24

resvg utility is making a bitmap of given pixel width/height, mapping the SVG's viewBox width/height onto the latter and clipping away what is outside. We may be able to retain the portion outside the viewbox by first stretching the viewbox to fit the union of all the paths' bounding boxes so we rasterize the entire outline, but then we have to think about how to reposition that bitmap in the font space. Which is already quite complicated, see #401

@anthrotype anthrotype changed the title Support unclipped viewebox for bitmap formats Support unclipped viewbox for bitmap formats Apr 4, 2022
@anthrotype
Copy link
Member Author

a linked problem is the fact that the bitmap pixel width/height cannot exceed 255 because CBDT metrics use uint8, so even if we do support the viewbox overflow, we could still incur in the nastier integer overflow:

#400 (comment)

@rsheeter
Copy link
Collaborator

rsheeter commented Apr 5, 2022

Ew. If we change the bitmap size our core computation of where the bitmap gets placed in font space breaks.

@rsheeter
Copy link
Collaborator

rsheeter commented Apr 5, 2022

I think we have to pre-process, "remember" the initial viewbox, alter the viewbox to include the stuff outside, rasterize that, and then use the initial viewbox when positioning the bitmap in font space. Tiresome but doable.

@rsheeter
Copy link
Collaborator

rsheeter commented Apr 8, 2022

This one from Amiri Quran Colored just isn't ever going to work well as a bitmap with these limits. I'm going to have to set the height in px to like ... 8.

image

anthrotype added a commit that referenced this issue Aug 17, 2022
this will make zero-width glyphs disappear when rasterized via resvg to PNG, because anything outside viewbox gets clipped (#402). Thus, running maximum_color --bitmaps with a font that has such zero-width glyphs will produce invisible empty CBDT/sbix glyphs until that issue is resolved.
However, removing this assertions allows us to support zero-width glyphs in vector color formats like OT-SVG/COLR (cf. #421)
anthrotype added a commit that referenced this issue Aug 17, 2022
this messes up horizontal positioning of glyphs with zero advance width, was added to prevent clipping of bitmap glyphs exceeding their viewbox (#402). The latter issue will be dealt with separately.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants