-
Notifications
You must be signed in to change notification settings - Fork 24
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
Stroke width is not transformed #157
Comments
I should add, here's an example of one of the original SVGs, my hacked SVG, and the SVG found in the |
Apologies for the slow response, we've been busy trying to update a chain of things after a spec (or pre-spec) shift for COLR v1 (https://github.com/googlefonts/colr-gradients-spec). The scale need sounds similar to #2 where you have a set of svgs but want a transform applied. |
I wonder if we can should explore adding OpenMoji to https://github.com/googlefonts/color-fonts? |
I'm having troubles understanding whether/how we should handle Right now, picosvg doesn't treat the svg root transform specially, but simply applies it the same way it would for an all-enclosing hypothetical However here they say that the default I even tried patching picosvg locally to interpret the root transform this way (i.e. equivalent of applying the combined I'm tempted to say that picosvg should not support |
Seems reasonable. I've not been able to test it yet, though, because if I use picosvg master I run into googlefonts/picosvg#138. |
- Itʼs suggested in googlefonts/nanoemoji#157 that we donʼt apply scaling by transforming the root `svg` element, but rather by enclosing the body of the SVG in an element that applies the transform. - Recent nanoemoji versions are configured with a file rather than on the command line.
Yes, wrapping everything in a |
- Itʼs suggested in googlefonts/nanoemoji#157 that we donʼt apply scaling by transforming the root `svg` element, but rather by enclosing the body of the SVG in an element that applies the transform. - Recent nanoemoji versions are configured with a file rather than on the command line.
- Itʼs suggested in googlefonts/nanoemoji#157 that we donʼt apply scaling by transforming the root `svg` element, but rather by enclosing the body of the SVG in an element that applies the transform. - Recent nanoemoji versions are configured with a file rather than on the command line.
- Itʼs suggested in googlefonts/nanoemoji#157 that we donʼt apply scaling by transforming the root `svg` element, but rather by enclosing the body of the SVG in an element that applies the transform. - Recent nanoemoji versions are configured with a file rather than on the command line.
- Itʼs suggested in googlefonts/nanoemoji#157 that we donʼt apply scaling by transforming the root `svg` element, but rather by enclosing the body of the SVG in an element that applies the transform. - Recent nanoemoji versions are configured with a file rather than on the command line.
I'm trying to build the SVGs from the OpenMoji project into a font, but the source SVG files typically contain a lot of padding around the edges, and hence each character appears rather small when converted.
To try to work around this, I'm hacking a
transform=scale(1.3)
attribute into the root node of each SVG file. This seems to work as expected if I view the hacked files with any SVG viewer I've tried, but it doesn't quite work correctly withnanoemoji
. The shapes are upscaled, but the stroke width is not.This can be quite hard to see, so for this screenshot I have exaggerated the effect with
![image](https://user-images.githubusercontent.com/120296/96346624-aedf3500-1094-11eb-9e35-74363300a2c3.png)
scale(10)
. Scaled:Unscaled:
![image](https://user-images.githubusercontent.com/120296/96346736-46448800-1095-11eb-8c5b-fcecc2ba0fc1.png)
Relates to hfg-gmuend/openmoji#260.
The text was updated successfully, but these errors were encountered: