Best software for 2-D font development
Steve Slevinski
Posts: 3
I work with Sutton SignWriting, a way to write any sign language. It consists of a large set of glyphs that can be combined in any 2-dimensional arrangement. You can view https://slevinski.github.io/SuttonSignWriting/ for more information.
For the individual glyphs, we started with PNG, upgraded to SVG, and finally imported into TrueType fonts using Python scripting in FontForge. The TrueType Fonts work on all platforms, but must be wrapped in SVG to support the 2-dimensional nature of the script.
Each individual glyph is positioned with XY coordinates. We have a proof-of-concept 2D font that works with Graphite. The font is defined with the Graphite Description Language in a python file. https://github.com/Slevinski/iswa_graphite/blob/master/iswa_graphite.py
Next year, I'm hoping to return to the font development and create a production ready 2D font. Right now I need to come up with a development plan, so I'm hoping for some feedback or ideas.
I've been told that MicroSoft's Universal Shaping Engine is a better platform than Graphite. The Universal Shaping Engine supports many of the same concepts as Graphite and the technology behind the Universal Shaping Engine is more likely to be supported by other operating systems in the future than Graphite's design.
If I'm targeting the Universal Shaping Engine, then MS-Volt seems like the natural software to use. I've been able to import our existing TrueType Fonts into MS-Volt without an issue, but I have not done much more than that.
Another complication is that SignWriting requires a 2-color font, one color for the outline and another for the background. The 2 colors are important when glyphs overlap; the negative space of the glyph on top can hide the outline of the glyph underneath. Currently, we are using 2 TrueType fonts to achieve this effect inside of the SVG.
If anyone has any thoughts or suggestions, I'd really appreciate the help.
For the individual glyphs, we started with PNG, upgraded to SVG, and finally imported into TrueType fonts using Python scripting in FontForge. The TrueType Fonts work on all platforms, but must be wrapped in SVG to support the 2-dimensional nature of the script.
Each individual glyph is positioned with XY coordinates. We have a proof-of-concept 2D font that works with Graphite. The font is defined with the Graphite Description Language in a python file. https://github.com/Slevinski/iswa_graphite/blob/master/iswa_graphite.py
Next year, I'm hoping to return to the font development and create a production ready 2D font. Right now I need to come up with a development plan, so I'm hoping for some feedback or ideas.
I've been told that MicroSoft's Universal Shaping Engine is a better platform than Graphite. The Universal Shaping Engine supports many of the same concepts as Graphite and the technology behind the Universal Shaping Engine is more likely to be supported by other operating systems in the future than Graphite's design.
If I'm targeting the Universal Shaping Engine, then MS-Volt seems like the natural software to use. I've been able to import our existing TrueType Fonts into MS-Volt without an issue, but I have not done much more than that.
Another complication is that SignWriting requires a 2-color font, one color for the outline and another for the background. The 2 colors are important when glyphs overlap; the negative space of the glyph on top can hide the outline of the glyph underneath. Currently, we are using 2 TrueType fonts to achieve this effect inside of the SVG.
If anyone has any thoughts or suggestions, I'd really appreciate the help.
0
Comments
-
I had a look at the .ttf file that is available to download from your site.
It does’t seem to contain any Graphite tables. So you have build a regular TrueType font. Graphite fonts usually contain information for layout for complex script (like Indic or Arabic). So you don't need Graphite or the Universal Shaping engine (it is used mostly for handling of complex script, too).
The outline quality is very, very bad.
The visually strait lines consist of a lot of unnecessary line and curve segment. That seems to come from the auto-tracing of the PNGs and TrueType conversation.
This is how it should look like:
The original had 65 nodes and the cleaned up version has 10. Not all glyphs are that bad, but I think the file size would be at least half of the 7.5 MB.
There are some color font formats available. This is a article explaining it: pixelambacht.nl/2014/multicolor-fonts/
To answer your original question. I’m the developer of Glyphs. It is a font design tool. It does support export of TrueType and color fonts.
0 -
Thanks Georg for taking a look. The graphite prototype font is available on another page. You can find it here. http://signpuddle.net/iswa/#smartfont
The file you downloaded only contains the individual glyphs without any 2-D positioning. There are 37,811 glyphs in the main font file. If you know of a way to automate the cleanup of the glyphs, I'd be interested to know. It would be nice to shrink the font files.
These glyphs are wrapped in SVG for the 2-D. You can see a segment of text on http://signpuddle.com/ using this font. An explanation of the SVG is available: https://slevinski.github.io/SuttonSignWriting/components/svg.html
Thanks for the link about color fonts.0 -
I didn’t see the other page.
Some of the paths can be automatically cleaned up. But some are so 'strangely' set up, that it would be much easier to redraw them. And using components, you can reduce the work needed to build a font like this significantly.
0 -
There are a number of things in play here:
First, the drawing of the glyphs themselves. Georg mentions components but this is the sort of thing that would be better scripted - for example, generating the rotated handshapes is something that can (and should) be completely automated. Any of the major font editing software (Glyphs, Robofont, Fontlab) would be suitable for this. Feel free to contact me for help; this is something I would want to give time to.
The second is the OpenType handling. Have you verified that SignWriting clusters can conform to the USE cluster model? That's the first step. I'm not convinced it would work but I have not spent much time trying to make it work; USE isn't really designed for this and you may find yourself shoehorning characters into categories that they were not designed for. I am also not sure how you would represent the two-dimensional numbers in a USE cluster. (I see you went with the 2D layout model instead of Martin's multiple attachment point model in the end - I understand why but that takes it further away from the way OpenType normally works.) Then given the complexity of what you're doing I suspect you would want to work in VOLT.
Then there is the transparency/fill issue. You talk about wrapping the font in SVG but have you considered going the other way and having SVG outlines in the font? There isn't much layout support for the SVG-in-OT yet but it's starting to be developed, and will almost certainly be there by the time you have worked out the OT layout issues.0 -
Thanks Simon. It would be nice to clean up the glyphs, but it's not something I'm going to spend time on right now.
Can SignWriting clusters conform to the universal cluster model? I'm hopeful, but not sure. Andrew Glass suggested I target USE with MS-Volt. He is working on complex hieroglyphics and is dealing with some of the same issues. Reading over the documentation for USE, I believe I can make it work but I'm not sure exactly how.
Martin is a great guy but we never agreed. SignWriting has been based on cartesian coordinates (X,Y) for the past 30 years, since the Apple 2C. Attachment points are simply a form of limited polar coordinates (degrees and distance) with an internal tree structure. Martin created an initial document you can find on ScriptSource, and there is some limited discussion on the Graphite Dev List from back in 2012.
I've thought about using SVG-in-OT, but by what I could find, it isn't supported widely enough yet. I have the glyphs available in SVG so it's definitely something to keep an eye on for later.0 -
Steve Slevinski said:
Another complication is that SignWriting requires a 2-color font, one color for the outline and another for the background. The 2 colors are important when glyphs overlap; the negative space of the glyph on top can hide the outline of the glyph underneath. Currently, we are using 2 TrueType fonts to achieve this effect inside of the SVG.
If anyone has any thoughts or suggestions, I'd really appreciate the help.
The "filled in" issues you mention in your video are all due to outline issues which should be solved by changing contour directions, removing overlap, or by removing unnecessary contours.Steve Slevinski said:Can SignWriting clusters conform to the universal cluster model? I'm hopeful, but not sure. Andrew Glass suggested I target USE with MS-Volt. He is working on complex hieroglyphics and is dealing with some of the same issues. Reading over the documentation for USE, I believe I can make it work but I'm not sure exactly how.
0
Categories
- All Categories
- 43 Introductions
- 3.7K Typeface Design
- 798 Font Technology
- 1K Technique and Theory
- 617 Type Business
- 444 Type Design Critiques
- 541 Type Design Software
- 30 Punchcutting
- 136 Lettering and Calligraphy
- 83 Technique and Theory
- 53 Lettering Critiques
- 483 Typography
- 301 History of Typography
- 114 Education
- 68 Resources
- 498 Announcements
- 79 Events
- 105 Job Postings
- 148 Type Releases
- 165 Miscellaneous News
- 269 About TypeDrawers
- 53 TypeDrawers Announcements
- 116 Suggestions and Bug Reports