Make SBOL Visual 2.0 font

[jakebeal]

Once upon a time, somebody made a font out of the SBOL Visual 1.0 glyphs - can we figure out how to make and maintain for Visual 2.0?

[BenjaminAleritsch]

I am currently working on a TrueType font for SBOL Visual 2.0. One first design for the nucleic acid glyph set can be found here.

My plan is to create four fonts:

• Above, for the nucleic acid glyph set and plasmid construction elements (rounded corners),
• the second for same but with composite glyph addition where required,
• third the interaction glyph set with interaction connectors (cross/merge/split etc) and
• fourth the molecular species glyph set.

In order to get the fonts as close as possible to the intended standardized design, I would like to collect information what specific changes in my current design are required.

What I did so far is as follows in

• Inkscape:
  • Import the svg files from the SBOL Github Rep
  • Scale them up to 3072px width
  • Create a layer for each glyph in Inkscape via Menu:Extensions/Typography/Add Glyph Layer
  • Add DNA baseline if needed
  • Convert from strokes to paths
  • Combine paths
  • Center & Align
  • Save all layers as one svg
• FontForge:
  • Open/Import above svg
  • Setup font information
  • Correct width to 4096px
  • Correct wrong direction
  • Add missing extremas
  • Correct non-integral coordinates
  • Correct intersecting paths
  • Generate Font

[cjmyers]

I think this looks great. There are though a few glyphs that I think you have straddle the line that should be on the line. This includes the unassigned glpyh, no specified role, and engineered region. Also, the polyA site, I think.

On Mar 31, 2018, at 6:52 AM, BenjaminAleritsch notifications@github.com wrote:

I am currently working on a TrueType font for SBOL Visual 2.0. One first design for the nucleic acid glyph set can be found here <x-msg://110/tinyurl.com/yd2ow2pl>.

In total my plan is to create four fonts:

Above, for the nucleic acid glyph set and plasmid construction elements (rounded corners), the second for same but with composite glyph addition where required, third including the interaction glyph set with interaction connectors (cross/merge/split etc) and fourth the molecular species glyph set. In order to get the fonts as close as possible to the intended standardized design, I would like to collect information what specific changes in my current design are required.

What I did so far is as follows in

Inkscape: Import the svg files from the SBOL Github Rep Scale them up to 3072px width Create a layer for each glyph in Inkscape via Menu:Extensions/Typography/Add Glyph Layer Add DNA baseline if needed Convert from strokes to paths Combine paths Center & Align Save all layers as one svg Font Forge: Open/Import above svg Setup font information Correct width to 4096px Correct wrong direction Add missing extremas Correct non-integral coordinates Correct intersecting paths Generate Font — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/SynBioDex/SBOL-visual/issues/29#issuecomment-377691019, or mute the thread https://github.com/notifications/unsubscribe-auth/ADWD98jMLanc1aS71Y18dZAYHJa77Jw_ks5tj3wmgaJpZM4RZN8C.

[jakebeal]

Is there a reason to split this into four fonts, rather than to have it all together in one unified font?

[jakebeal]

Another question: what is determining the ordering in the font? I am looking at it with "Font Book" and the order looks sort of alphabetical but not quite. It also appears to be missing some elements (e.g., ORI-T, assembly scar).

[BenjaminAleritsch]

@cjmyers Is there a source that specifies the exact position of the glyph relative to the baseline? If not I would just update the current version according to my personal judgement concerning distance to baseline / relative position when it comes to moving those symbols from in the line to atop/beneath of it.

@jakebeal Since there is one glyph for each the 5' and 3' direction, there are too many glyphs for a single font, but I have not investigated the full potential in e.g. using the underline/bold/italic option for a font for e.g. the composite symbols. I think I would only use numbers and letters except y/z if possible since special characters and y/z change position with the keyboard layout. I tried to keep up sort of an alphabetical order which is not always possible (multiple glyphs with same first letter). I am totally open to suggestions how to map which character/key to which glyph. Some elements are missing since I have not figured out the encoding properly i.e. assigned glyphs to certain keys but they do not appear when I press the key. I am working on that issue.

[jakebeal]

On the subject of the backbone: each nucleic acid glyph has a "[glyph]-specification" file that includes the recommended placement of the backbone, shown as a dashed grey line. For example, the signature glyph specification is recommended to sit on top of the backbone:

With regards to number of symbols --- modern fonts have huge number of symbols via unicode. I would suggest that it might be a good idea to use the unicode private block for defining the symbols, ordered as they appear in the spec. There's a lot of space in the privateblack, and it follows best practices for extending with new classes of characters. That does mean one couldn't just type a - z, but that's not the recommended approach for non-standard font symbols in any case.

[hsauro]

Nice idea, I presume these will work with LaTeX.

Herbert

On Sat, Mar 31, 2018 at 5:53 AM BenjaminAleritsch notifications@github.com wrote:

I am currently working on a TrueType font for SBOL Visual 2.0. One first design for the nucleic acid glyph set can be found here http://tinyurl.com/yd2ow2pl.

In total my plan is to create four fonts:

• Above, for the nucleic acid glyph set and plasmid construction elements (rounded corners),
• the second for same but with composite glyph addition where required,
• third including the interaction glyph set with interaction connectors (cross/merge/split etc) and
• fourth the molecular species glyph set.

In order to get the fonts as close as possible to the intended standardized design, I would like to collect information what specific changes in my current design are required.

What I did so far is as follows in

• Inkscape:
  • Import the svg files from the SBOL Github Rep
  • Scale them up to 3072px width
  • Create a layer for each glyph in Inkscape via Menu:Extensions/Typography/Add Glyph Layer
  • Add DNA baseline if needed
  • Convert from strokes to paths
  • Combine paths
  • Center & Align
  • Save all layers as one svg
• Font Forge:
  • Open/Import above svg
  • Setup font information
  • Correct width to 4096px
  • Correct wrong direction
  • Add missing extremas
  • Correct non-integral coordinates
  • Correct intersecting paths
  • Generate Font

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/SynBioDex/SBOL-visual/issues/29#issuecomment-377691019, or mute the thread https://github.com/notifications/unsubscribe-auth/ABAZDtFbGDPDAXcuICKtIJkT28lP7_uGks5tj3wmgaJpZM4RZN8C .

[BenjaminAleritsch]

@jakebeal ok, I will correct/remake the symbols according to the position specification. Should the symbols in the other direction be inversed, mirrored or moved below the baseline? I would use the unicode private block in between of U+F0000 and U+FFFFD then. However, my initial intention was to make it very easy to use the SBOL symbols for users without any knowledge in python, latex etc. That is why I wanted to use keys found on the most common keyboards. Even though I'll create a "proper" version with unicode encoding, I would also want to create one in that manner since most people I know who are working in the field create their publications with Microsoft/Libre office software. When a "more or less" final version of the font or the glyphs has been established, we could also think about requesting to add SBOL to the unicode standard symbol set.

[jakebeal]

Per the section on Nucleic Acid Sequence Features in the 2.0.0 spec, it is recommended that

any glyph that is associated with the reverse complement strand SHOULD be inverted vertically and horizontally (i.e., rotated 180 degrees)

That rotation is around the backbone, so a glyph that was above ends up below.

That unicode block sounds like a fine place to put it --- and I believe will actually quite easy for people using Microsoft/Libre Office to access, through the "insert symbol" functions in those programs. That is how I, at least, insert all of my symbolic characters already, rather than trying to remember what key they might have been assigned to in WingDings.

I do also anticipate asking for SBOL to be added to unicode at some point in the future, but I believe that we need to have a better established history of it being used in text before that happens.

[BenjaminAleritsch]

Ok all clear, I'll get to it.

[BenjaminAleritsch]

I added the file InkscapeImport.svg here. It contains all the vector images which I built from the Glyphs (in different layers: Press Shift+Ctrl+L). Before I continue with importing them into FontForge, I would like you to confirm if everything is ok.

[jakebeal]

I've reviewed them and have only a few adjustments to request:

• IDs of plasmidring - please cluster them together like you do like the rest of the lines
• blunt restriction site should not have a break in the backbone
• If we're going to have combinations for SuperposeGlyphs complexes, we should also include MoleculeDNA
• Complex_alternative is scaled too large - it should be the same width as Macromolecule_alternate
• arrow scaling is inconsistent

[BenjaminAleritsch]

I just updated the file after correcting the first four issues. How exactly is arrow scaling inconsistent?

[jakebeal]

The length of the tail varies greatly based on orientation and head. I think the Degrade collection is the only one that is consistent between vertical and horizontal orientations.

[BenjaminAleritsch]

Concerning the tail the Degrade part is the only part for which I created an exception since the symbol is too big to fit into the space used everywhere else. I also decided this way since degradation does not have a target as stimulation, control,inhibition or process do. Can you give me specific input how this should be solved?

[jakebeal]

My recommendation would be to follow the practices used for arrows in other fonts, and thus have the tails all the same length, regardless of orientation.

[BenjaminAleritsch]

I just updated the file. I changed the degradation symbols so that they are consistent with the others interaction arrows, treating the degradation symbol itself as "outside" of the frame.

[jakebeal]

I just looked at the new file; all of the other issues look well resolved.

Regarding the arrows: the different types are all consistent, but the vertical and horizontal are still very different lengths. My suggestion had been to make vertical = horizontal, like other arrows are in most fonts, e.g., →↑←↓

Is there are reason that you think this would be a bad idea?

[BenjaminAleritsch]

Horizontal and vertial have different lengths since the glyph size is not quadratic (4096x8192) and in order to forge connections with neighbouring glyphs, the arrow-lines should start at the edge of the frame. To be explixit, lines even start 10px outside of the frame in order to fix rendering problems that I encountered. The lines must also end at the border since the heads of the arrows "interact" with glyphs outside e.g. the inhibition or control of a macromolecule. If the inhibition-arrow's head is not at the border of the frame, interacting symbols are too far away or it does not look too good. I could solve this by quadratic frames, however, then the spacing between the glyphs on the dna would not look very good anymore. I think keeping arrow glyphs with different line-lengths for horizontal and vertical arrows is the best solution here.

[jakebeal]

I'm afraid that I'm a little big confused: most fonts allow characters to have different widths. Is there some reason that we can't have the horizontal arrows have a different width than other characters?

[BenjaminAleritsch]

Keeping the same width for all characters assures that there is no misalignment between lines when creating i.e. plasmid "loops".

[jakebeal]

If the arrows are double normal width (8192x8192) then that should be able to be dealt with by a "plain backbone" spacer.

[BenjaminAleritsch]

Then it cannot be centered above/under a glyph that is on dna.

[jakebeal]

What if you do just the horizontal arrows that way? That would allow the vertical arrows to be centered, but horizontal arrows would connect left/right instead.

[BenjaminAleritsch]

Good point. Just updated the file. If everything is ok now, I would proceed to create the font.

[jakebeal]

It's all looking good to me now! Go ahead and create the font!

I do see one typo-level thing you'll likely want to adjust while doing so: among the reverse-complement glyphs, some are called "inversed" and some "inverted", and I expect you probably intended to have them all use the same word.

[BenjaminAleritsch]

Ok, I'll take care of that. One final question: Is there an SBOL logo svg file i.e. a vectorized SBOL logo available? My intention was to split it up to four images and assign it to the letters S,B,O and L, so that in word processors the logo is shown in the font selection dropdown list. If there is no svg-file for the logo, I would trace the file used on the SBOL landing page.

[jakebeal]

The SBOL "Community Media" repository has the current logos, including an svg version: https://github.com/SynBioDex/Community-Media/tree/master/miscellaneous/logos_2018

[BenjaminAleritsch]

I updated all files. For now the font is finished, however I encounter three issues I have left to resolve for which I would be happy if you could share some input:

• Pressing space does not create an empty 4096px-width character so symbols are misaligned. For now I created a workaround by inserting an empty DNA-element, selecting white as color as substitute for an empty character.
• When zooming or scrolling I can see what I thought were rendering errors. However, dependent on the state of the displayed "rendering error", it can be exported into a pdf and is fixed there then i.e. can not be resolved or changed by scrolling/zooming anymore.
• Inversed composite extension lines have to be added if inversed (extended) composite is actually an intended usecase.

[jakebeal]

Great news!

My thoughts on your remaining issues:

• Why aren't you able to control the width of the space in your font? I don't understand something about why this might be going wrong.
• Do the rendering errors show up in all programs, or just inkscape? I wouldn't be surprised if there's just something wonky in inkscape, but if they show up in professionally developed things like TextEdit, it may be worth worrying about.
• Inverted composite isn't expected to be an important use case, but I don't see any particular reason to exclude it, since you've added inverses of everything else.

[BenjaminAleritsch]

Fixed the issues:

• I "found" the glyph that is "space" and assigned an empty field with with 4096
• Rendering errors only show up in word processing programs like Libre Writer. I removed the 10px extensions, since even with width set to 4096, glyphs were 4116 in width (except the ones without dna base), which caused the misalignment. Now the the glyphs have uniform width.
• Inverted composite extensions have been added.

Got new issues:

• When using a font size other than 12, misalignment and gaps re-appear (see bottom of Examples.pdf).

[jakebeal]

Maybe it's close enough for a first release in any case?

[BenjaminAleritsch]

I agree. What is left to fix are only minor details. What are the next steps?

[jakebeal]

I think that the next thing is to add a README to your font directory that explains:

• How to install and use the font
• The principles that were used in designing and testing the font
• How to update the font when new symbols are added
• How to test that an update has been completed correctly.

Once that's done, please initiate a pull request! The editors and I will review and approve (hopefully with no more changes needed).

Normally, we would bring updates into the develop branch, but since this isn't a spec change, but a new implementation artifact for the current spec, I think that we can merge directly into master.

[jakebeal]

Fixed via #43