Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Fix viewBox in exported SVG glyph #3395
Export a glyph as an SVG, like
And the bottom continues to be cut off when you resize the window. So what's going on?
The relevant export code starts this way:
In the FontForge geometric space descent (in the typography sense) corresponds to decreasing
The intent of the
After that change, which is all this pull request is, if you export that character as an SVG you get the other file in the zip, which looks like this in a browser:
The remaining worry is whether the
Types of changes
What types of changes does your code introduce? Check all the boxes that apply:
Go over all the following points and check all the boxes that apply.
Your pull request will be tested via Travis CI to automatically indicate that your changes do not prevent compilation. FontForge is a big program, so Travis can easily take over 20 minutes to confirm your changes are buildable. Please be patient. More details about using Travis can be found here.
If it reports back that there are problems, you can log into the Travis system and check the log report for your pull request to see what the problem was. If no error is shown, just re-run the Travis test for your pull-request (that failed) to see a fresh report since the last report may be for someone else that did a later pull request, or for mainline code. If you add new code to fix your issue/problem, then take note that you need to check the next pull request in the Travis system. Travis issue numbers are different from GitHub issue numbers.
Ugh, pushed too soon. I forgot
I pushed a better version of
This seems to work by only changing the horizontal values, never the height, therefore roundtrip exports to an SVG editor, having edits applied, and reimported to FontForge seem to work fine for me. FontForge (for some reason) has never supported setting the bearings used for kerning based on SVG data.
Are there any situations you are aware of where round-trip SVG imports won't work (or will require e.g. rescaling) with this new viewBox code, @skef?
In the case of
Speaking more generally, the SVG import code appears to be intended to work with a variety of code styles (within limits) and just uses the viewBox for scaling hints.
It did occur to me that it could be handy to encode the Y value corresponding to FontForge space 0 and the X value of the advance width in some kind of structured comment in the export, so that those could be recovered during a round-trip. But that seemed like it would require discussion outside the scope of this little change.
If we were to add the X value of the advance and Y value of the start of the descender, it would be more logical to use