Increasing the capabilities of the Template Editor

Got a request? Post it here. Please do not post bug reports here.
Post Reply
William
Top Typographer
Top Typographer
Posts: 2038
Joined: Tue Sep 14, 2004 6:41 pm
Location: Worcestershire, England
Contact:

Increasing the capabilities of the Template Editor

Post by William »

In the Scanahand 4 Template Editor, one can include a sequence of items such as the following, namely a single code point and a range of code points, an item separated from the next item in the sequence by a comma.

$E001

$E005-$E100

Suppose that there were the option available to place a lower case n in front of the first, or only, $ in each item, as follows.

n$E4C2

n$E500-$E50B

In a sequence, some items could have an n and some not have an n, as desired.

If there were an n then the glyph for each character cell in that item would have no white space at either the left or right side of the glyph.

So, for example, if one wanted to make a font that includes an arabesque combining border in the twelve locations U+E500 through to U+E50B, then one could include the following in the sequence of codes in the template editor, thereby stopping there being any white space to the left or the right of the glyph, so that the combining border would work well straight away without needing to adjust the font manually in FontCreator.

n$E500-$E50B

Suppose that there were the option available to place a lower case s in front of the first, or only, $ in each item, as follows.

s$2000-£200A

s$E50F

If there were an s then the glyph for each character cell in that item would have no contours at all, but the advance width would be produced as if the glyph were there and the n had been used. The end user would draw a line as long as the width of the desired space, or, for an arabesque designed using Microsoft Paint, simply paste a copy of one of the arabesque glyphs into the cell so that Scanahand would be able to know the desired width of the space.

This would enable space characters of known width to be included in the font.

For example, the use of U+E50F is for a space of the same advance width as a unit from the arabesque, so that arabesque designs with holes in them can be produced straightforwardly.

I produce artwork for Scanahand mostly directly in Microsoft Paint using a .png version of the template file.

The examples refer to U+E500 through to U+E50B and also U+E50F.

This is because those are the code points that I used for an arabesque in my Quest text font.

I have tried an arabesque using Scanahand 4 using just U+E500 through to U+E507 so as to try the technique of making a template and then making some artwork and making a font. The technique works well, but the white space to the left and right of the glyphs mean that they do not join together as they ideally should when used in an application program such as WordPad. I could adjust the font manually using FontCreator. However, if the n facilty and the s facility were added into the template editor then including an arabesque into a font directly from Scanahand alone would be possible.

The n facility might also be useful for making fonts where the desire is to produce letters that join together.

William Overington

10 May 2013
William
Top Typographer
Top Typographer
Posts: 2038
Joined: Tue Sep 14, 2004 6:41 pm
Location: Worcestershire, England
Contact:

Re: Increasing the capabilities of the Template Editor

Post by William »

Please note that this post has changed from the original version.

The changes are that I have now used lowercase i to request a ligature in the liga table.

I had originally used c, so as to avoid using lowercase l so as to avoid any mixups over confusion between lowercase l and figure 1. However, I now realize that c might be better used for a clig ligature request if that is possible, so I thought it best to change to using i for a liga request.

William Overington

12:41 pm 13 May 2013

----

Earlier this morning I was reading the following thread.

viewtopic.php?f=22&t=3740

High-Logic has now developed OpenType font facilities for FontCreator 7.

So here are some more suggestions for the Template Editor.

Suppose that an end user can produce an automated ligature in one of two ways, either using a lowercase i before the first $ in a sequence in the Code Points panel for a ligature or a lowercase d before the first $ in a sequence in the Code Points panel for a discretionary ligature.

Suppose that this had already been implemented and someone wishes to add a ct ligature as a discretionary ligature.

In the Characters panel, he or she could add the following.

[ct]

The square brackets for a dlig ligature. Had a liga ligature been desired, round parentheses would have been used instead of the square brackets.

Switching to the Code Points panel, the ligature has become expressed as follows.

d$0063+$0074

Had a liga ligature been desired, an i would be in front of the $.

That would do, for an unmapped ligature for an OpenType font.

However, the end user has a friend who is using WordPad and does not have an OpenType-aware application to use, so the end user decides to map the glyph into the Private Use Area as well.

d$0063+$0074=$E707

Yet the end user remembers that there is also the MUFI system that maps a ct ligature to U+EEC5.

So the end user decides to map the glyph to two code points.

d$0063+$0074=$E707:$EEC5

Going back to the Characters panel, the ligature request is displayed using a black square for each of U+E707 and U+EEC5.
In this post, a black square is represented by a capital Q.

[ct=Q:Q]

The end user now wishes to add an alternate glyph for a letter g.

This time he or she enters, in the Characters panel, the following.

{g}

Switching to the Code Points panel, this displays as follows.

a$0067

Remebering his or her friend using WordPad, the end user decides to map the glyph to the Private Use Area.

a$0067=$EA60

This is because U+EA60 can be accessed using Alt 60000 in WordPad, thus making things easier for his or her friend.

Going back to the Characters panel, the display uses a black square for U+EA60. In this post, a black square is represented by a capital Q.

{g=Q}

The end user then decides to add a second alternate glyph for lowercase g.

Another end user does not add Private Use Area mapping to glyphs for ligatures and alternates, so simply adds the following in the Characters panel.

(fi) (fl) (ff) (ffi) (ffl) [ct] [st] [pp] (Qu) (Que) {g} {g} {p} {e} {e} {e}

So the cells for drawing appear in that order in the template.

I am wondering if one could have an alternate glyph for a ligature.

{ct}

There are other facilities in OpenType so if other readers wish to extend, or alter, the above ideas, please feel free to do so.

William Overington

13 May 2013
Last edited by William on Mon May 13, 2013 11:52 am, edited 3 times in total.
William
Top Typographer
Top Typographer
Posts: 2038
Joined: Tue Sep 14, 2004 6:41 pm
Location: Worcestershire, England
Contact:

Re: Increasing the capabilities of the Template Editor

Post by William »

In addition, it appears that rlig capability would be desirable as well.

I suggest using an r before the $ in the Code Points panel and using < and > in the Characters panel.

William Overington

13 May 2013
William
Top Typographer
Top Typographer
Posts: 2038
Joined: Tue Sep 14, 2004 6:41 pm
Location: Worcestershire, England
Contact:

Re: Increasing the capabilities of the Template Editor

Post by William »

Please note that post timestamped at 09:54 am this morning has changed from the original version.

The changes are that I have now used lowercase i to request a ligature in the liga table.

I had originally used c, so as to avoid using lowercase l so as to avoid any mixups over confusion between lowercase l and figure 1. However, I now realize that c might be better used for a clig ligature request if that is possible, so I thought it best to change to using i for a liga request.

William Overington

13 May 2013
William
Top Typographer
Top Typographer
Posts: 2038
Joined: Tue Sep 14, 2004 6:41 pm
Location: Worcestershire, England
Contact:

Re: Increasing the capabilities of the Template Editor

Post by William »

Please note that, from my general experience with OpenType, that random alternate proved to be problematical, so maybe some way of signalling a contextual alternate in a Scanahand template is needed instead.

William Overington

14 December 2013

The original post is unaltered as a matter of record.

----

Quoting from the following post.

viewtopic.php?p=19060#p19060
William wrote: So what is the best way to add a feature to what I have suggested about requesting alternate glyphs in the Scanahand Template Editor so that the completed font can signal to an application program the desire to use Randomised Letter Forms?

Would a * character immediately before the closing bracket be a good solution, or is more needed?

For example, as follows.

{g*}

Switching to the Code Points panel, this displays as follows.

a$0067*

For the example situation described in an earlier post in this thread of the end user remembering his or her friend using WordPad, where the end user decides to map the glyph to the Private Use Area.

a$0067=$EA60*

This might not be all that is necessary to get maximum flexibility, but it might perhaps be a good start.

William Overington

13 May 2013
William
Top Typographer
Top Typographer
Posts: 2038
Joined: Tue Sep 14, 2004 6:41 pm
Location: Worcestershire, England
Contact:

Re: Increasing the capabilities of the Template Editor

Post by William »

Please note that, from my general experience with OpenType, that random alternate proved to be problematical, so maybe some way of signalling a contextual alternate in a Scanahand template is needed instead.

William Overington

14 December 2013

The original post is unaltered as a matter of record.
William
Top Typographer
Top Typographer
Posts: 2038
Joined: Tue Sep 14, 2004 6:41 pm
Location: Worcestershire, England
Contact:

Re: Increasing the capabilities of the Template Editor

Post by William »

Here are three examples of a format that might be suitable to request a calt encoding from a Scanahand template.

*t[aep]

*[aeh]g

*[aeh]f[aep]

However, as the t g and f might be swash glyphs, the glyph width would need to be calculated based on ink between baseline and x height only, with some side space for swash and no side space for cursive, so maybe one or two more codes are needed to request no side space for cursive.

Please regard this idea as fun with coding, though maybe it could be adapted to work and enable templates to be produced that would be fun for many people to use to produce beautiful fonts.

William Overington

14 December 2013
Post Reply