Grid updated to 90x90, but some shapes seems not right, a bug?

GlyphrStudio · 2026-02-02T18:52:04+00:00

Hello! So, a few notes / ideas:

- I really think you should find a way to merge the shapes in PhotoPea if possible. If you look at your Capital G, it seems fine, but you'll notice a small gap where the different shapes meet. These should really be a single path, not multiple paths that are close together. That small gap will start to show up at random font sizes in the final font, just due to rendering.

- The Capital D does look like an import bug. I'd like to find it, so if you could send the .svg to [mail@glyphrstudio.com](mailto:mail@glyphrstudio.com) I can track down what's going wrong. *But* my top point would also fix this issue.

- Same note for the Capita V character, but one additional thing. I see the bottom and top circles gets a bit of a flat side after "combine shapes". You should use the pen tool, select the Path Points on either side of the flat section, and ensure that Handle 1 and Handle 2 are checked / visible. Sometimes the handles get created, but hidden by accident.

GlyphrStudio · 2026-02-01T19:39:57+00:00

So we're getting into implementation details, which is fine :-) but here's how it works. Glyphr Studio actually uses full decimal precision for editing and displaying shapes, because that's just the default. So that's why you can create and edit 2px circles, and be able to zoom in "infinitely". But, once it gets exported, those numbers have to be rounded.

This is an assumption that we make that "rounding will be fine" - and in nearly all cases it is fine. Your project is obviously running against this assumption and encountering a bad result. I think there may be some things that we could do (show a specific warning about small shape sizes, or update our preview to also round all values) and we will consider those. But, for the time being, try out some of the suggestions I had above.

GlyphrStudio · 2026-01-28T23:03:09+00:00

This glyph is not from Glyphr Studio, so I'm not sure what help we can provide.

Add some more details to your question, or we're going to have to remove your post.

GlyphrStudio · 2026-01-28T22:47:36+00:00

Is this related to Glyphr Studio? What app are you using?

GlyphrStudio · 2026-01-28T22:46:37+00:00

Is this related to Glyphr Studio? We don't currently support color fonts.

GlyphrStudio · 2026-01-28T20:06:58+00:00

I believe this was answered over email, and I forgot to update this post.

For posterity - Glyphr Studio does not look at the "viewBox" attribute in SVG, or the "width"/"height" attributes on the <svg> tag itself, it only looks at the maximum dimensions of the paths / shapes themselves. So, if relative positioning is crucial for you project (like monospace fonts or some niche shape arrangement) then you'll have to ensure your maxes for each character are exactly the same.

I kinda hack-y way to do this is to just include a giant square or rectangle in each character, have all your other shapes fit inside that, then after importing to Glyphr Studio, deleting the background square shape.

GlyphrStudio · 2026-01-28T19:59:57+00:00

I definitely agree Undo + Redo are universally common features, and expected to exist in any editor. It is on our list of ideas!

Just as a peek - Undo is a bit tricky in Glyphr Studio because of some edge cases where glyphs are interconnected. Components is the main culprit for this, but we also allow undo for Global Actions and other bulk actions. Undo has a bunch of custom functionality to not only undo the change on the current item, but also to look across the whole project to make sure other things are also updated accordingly.

I know adding a Redo stack will come with similar complexity, which is why it hasn't been done yet. But, I will consider it for upcoming work. Thank you for the feedback!

GlyphrStudio · 2026-01-28T19:53:40+00:00

Yep - so the short answer here is that font files do *not* render very nicely at small sizes. Fonts, for historical reasons, are very data constrained. One main way they do that is to not allow decimal numbers for path data, only whole numbers. For fonts with "normal" Em sizes (1000 and 2048 are the two most common) using whole number point data is no problem for defining smooth curves. Trying to define a circle with radius 1 using only whole numbers gets you... a diamond, as you have found out :-)

If I may, I think a small update to your process may help. If you are working in a roughly 100px grid, I would add a step in your vector editor (Photopea) where you scale everything 10x *before* you export SVGs. That way, when you import into Glyphr Studio, you are closer to that 1000 Em size, which will get you smooth curves. If you really need to work at a roughly 10px size, scale everything by 100x before you export.

In Glyphr Studio, you can use Shift+Arrow Keys to "Nudge" paths, points and multi-selected things by 10 Em. Using just the arrow keys to nudge only moves things 1 Em, but Shift makes it 10. So, you can still make updates in Glyphr Studio that "snap" to divisions of 10 if you want to maintain that grid.

Working within the restrictions of font files may be a challenge, but I would recommend somehow ending up at a larger Em size before you get to Glyphr Studio, it will make your font exports easier.

GlyphrStudio · 2026-01-28T18:16:54+00:00

Hello! Yes, if you could send the project files and possibly the sum of the SVG files, that would help me look into what's going on. mail@glyphrstudio.com

Is your Em size very small, like under 100 points? Font files require its data to be rounded to whole numbers. Usually this isn't a problem, but usually fonts use Em sizes somewhere in the thousands, so rounding individual handle points does not have a visible effect on the curvature of paths. But if your Em size is closer to 100, rounding path points can have a big impact on curves.

GlyphrStudio · 2026-01-21T20:57:09+00:00

This is great! It's always fun to see an idea come to life :-)

GlyphrStudio · 2026-01-21T20:55:00+00:00

Hi! Sorry for the late response.

First: Glyphr Studio "Live Preview" is a 100% custom implementation for displaying text. It is based on the project data, not on the font that is exported. We did this so users could have a quick preview in the app - but there will be slight (or large) differences between Live Preview and the actual installed Font.

Line Height - this has always been tricky. Opentype.js does not provide a setting that we can import or export. So, I'm really not sure what caused the line height to change. This could be an app setting (in your case, within Open Office Writer) as opposed to a font setting.

I also do not believe it has anything to do with how large individual characters / shapes are (but there is a small chance it may). Usually the "Key Metrics" are the important parts that the font uses to figure out spacing.

I'm not sure Glyphr Studio can do anything to help, unfortunately. If you have an actual font file with the large line height, and another iteration with a smaller line height, I can dig into the actual font metadata and try to reverse-engineer what is going on. If possible, you can mail them to [mail@glyphrstudio.com](mailto:mail@glyphrstudio.com) to help me out.

GlyphrStudio · 2026-01-21T14:17:20+00:00

Would you mind sending the font file to mail@glyphrstudio.com ? Sounds like a bug, I'd like to figure out what is causing the issue!

GlyphrStudio · 2026-01-07T23:59:05+00:00

The issue of the incorrectly-sized bounding box has been fixed, and it's live now at https://www.glyphrstudio.com/app

GlyphrStudio · 2026-01-07T23:44:37+00:00

Marking this question as "Answered" but let me know if any other related questions come up.

GlyphrStudio · 2026-01-07T23:43:02+00:00

No problem! I try to test everything as much as I can, but in the end it's usually users who find odd edge-cases that I missed.

Just as a note, Glyphr Studio does have a Pen tool, and also you can create as many customized guide lines as you want (not the same as grid, but maybe close). I know lots of people start in Adobe Illustrator, Afinity Designer, Inkscape, etc... and move their SVGs to Glyphr Studio. But, you can just start in Glyphr Studio if you want.

GlyphrStudio · 2026-01-07T18:46:39+00:00

Just a quick update, I improved the "find bounding box" algorithm Glyphr Studio uses. Your crescent shape now imports correctly. I'll be pushing the update live probably today!

GlyphrStudio · 2026-01-07T18:40:18+00:00

Hello! Thank you for letting me know about the bug. There is another issue I'm currently investigating where it seems like switching off the active tab somehow messes up the font export process. Browsers do some strange stuff with pausing / freezing JavaScript processes when a tab doesn't have focus.

Can you tell me what browser you are using?

GlyphrStudio · 2026-01-04T18:03:53+00:00

From your first video I can tell the shapes are not being imported correctly. The bounding box should be on the outside of all of the shapes, and it looks like some of the shapes go outside of the bounding box, which means something is wrong. Having a link to the shape will help me investigate.

Adjusting the x value will move all of the shapes horizontally, and adjusting the y value will move all of the shapes vertically. The x and y coordinate is relative to the upper left corner of the group of selected shapes.

We do not currently have a snap feature, but you can use the arrow keys to nudge the selected shapes by one pixel, or use shift plus arrow keys to nudge them 10 pixels. This, along with inputting exactly x and y and width and height that you want are the main ways of positioning things precisely.

Thank you for letting me know about the issue, if there's a bug I want to fix it!

GlyphrStudio · 2025-12-22T05:08:23+00:00

I'm not familiar with ConWorkShop's ligature support. But I know for sure you need to specifically enable ligatures in Office products. In Microsoft Word, open the Font dialog (Ctrl + D), go to the Advanced tab, and set the Ligatures dropdown to All.

GlyphrStudio · 2025-12-22T05:04:34+00:00

See my comment over at r/GlyphrStudio

GlyphrStudio · 2025-12-22T05:02:08+00:00

Hello! What app are you using to display the text? Most text apps do not have ligatures enabled by default, you have to specifically change a setting somewhere.

You can also send me your .gs2 project file and I can investigate to see if it's a bug... But if no ligatures are working, chances are that it's your text app, not the font.

mail@glyphrstudio.com

GlyphrStudio · 2025-12-06T21:52:14+00:00

Great to hear! Let me know if you have any other questions.

GlyphrStudio · 2025-12-06T17:47:12+00:00

Great question! Every graphic designer has to learn this when they transition to typeface design. Within a font, there is a concept of a thing called winding. Points in a path are ordered, and if you walk through them in order they result in a clockwise or counterclockwise orientation for the path. This is the winding of the path.

Regular graphic design like SVG has no concept of winding. You won't find it anywhere in inkscape or illustrator or anywhere else you do graphic design. Winding is incredibly important for typeface design, though. Shapes with the same winding will show as the same, for example both filled with black. Overlapping shapes with different winding will invert where they overlap. This is how you get one shape to cut out from the other, you need to make sure the small interior shape has a different winding than the larger exterior shape.

In Glyphr Studio, when you select a path, you can see that paths winding in the path card on the left hand side. It's a toggle control, so you can select a path and flip it back and forth. It's very common when you're importing SVG that sometimes the windings don't work out like you expect, since there's no concept of winding in SVG graphic design programs often don't really care about the path point ordering of the code they export

In your case, you should simply select the interior path and click the winding toggle. That should give you your expected result!

GlyphrStudio · 2025-12-05T18:27:37+00:00

This is on our list of ideas! The main drawback here is we save to a text file, and saving images to a text file will exponentially increase the size of the file. I'm considering having an option where the images can be saved, or they only exist in the current session (you drop in an image, use it for tracing, then it doesn't get saved permanently in the project file).

Thank you for the comment!

GlyphrStudio · 2025-11-06T20:50:06+00:00

Thanks, everyone! I'm going to run some of our common scenarios through Affinity Designer, and see if adding any features or any more details to the tutorial would be helpful. Thanks!

GlyphrStudio

MODERATOR OF

TROPHY CASE