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

Problematic characters #12

Open
2 of 5 tasks
azsn opened this issue Oct 4, 2020 · 0 comments
Open
2 of 5 tasks

Problematic characters #12

azsn opened this issue Oct 4, 2020 · 0 comments

Comments

@azsn
Copy link
Owner

azsn commented Oct 4, 2020

  • of NotoSansCJKjp-Regular: Made of ~100 beziers, which is currently too many. Maximum is floor( ((bezier atlas width)-2) / 3 ) (currently 84) because all the beziers for one glyph must be in one row of the atlas. This can be solved by using a one dimensional buffer (e.g. Buffer Texture backed by a Shader Storage Buffer Object) instead of a 2D texture acting as a data buffer for the bezier atlas. [Fixed in 6aa072d by using buffer textures which removes this 84-beziers limit.] [This glyph still doesn't render completely right due to detail density, but that's covered in another bullet below].

  • Any character in a font which uses cubic beziers. (A known offender is NotoSansCJKjp-Regular.) The algorithm as-is cannot handle cubic beziers, and although it could be made to handle them, it would require finding 3rd order polynomial roots in the fragment shader. So probably a better solution is to convert the cubics to quadratics up to some resolution limit before generating the atlases. [Fixed in 4cc6d9f by converting cubics to quadratics during the outline decompose phase.]

  • ç, Ç of LiberationSans-Regular: The intersection between the c and the ¸ renders corrupted. Not yet sure why. Based on how the corruption looks, I suspect it's related to the cell midpoint-inside detection algorithm (GridGlyph.cpp find_cells_mids_inside()).

  • Any glyph which requires over 254 beziers. Any of a glyph's beziers must be able to be referenced by one byte in the grid atlas, minus two values for storing metadata. I have yet to see any glyph even coming close to 254 beziers, so I don't think this a big problem. Could solve by splitting up single glyphs into multiple rendered glyphs, e.g. 4 quadrants each getting ~1/4th the beziers (might have some overlap).

  • Any glyph which is too dense in detail and has regions which break the "4 beziers per grid cell" limit at the current fixed grid size of 20x20. Examples: . Making the grid size larger fixes this problem for most glyphs, but increases memory usage for the glyphs that do not need it. Also, at large grid sizes, glyph rendering breaks down for unknown reasons (all characters, not just this one). One solution would be a variable sized grids (perhaps packed into one atlas or separated into multiple based on grid size). Will Dobbie's original solution was to have two grids, a 2nd as an "extra" which means up to 8 beziers are allowed per grid cell. This might be able to be generalized to any number of grids per glyph, adding more as needed (e.g. using 3D textures).

(To be continued as more are discovered.)

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

1 participant