-
Notifications
You must be signed in to change notification settings - Fork 23
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
Comments
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: |
Ew. If we change the bitmap size our core computation of where the bitmap gets placed in font space breaks. |
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. |
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)
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.
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:
The expected result should look like the COLRv1 version (OT-SVG also works):
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
The text was updated successfully, but these errors were encountered: