FontArk

Nick Shinn

Usually, upper case /I in a sans serif has no crossbars.
This is a “legibility affectation”, IMHO!

Ofir Shavit

Ok got it, this will make things easier
Segoe ui has it. I'll take them of. Thanks.

LeMo aka PatternMan aka Frank E Blokland

Nick: ‘I prefer to have math operators low, not vertically centered.’

I prefer them vertically centered on tabular-figures height for tabular figures, vertically centered on old-style figures height for old-style figures, and vertically centered on smallcaps-tabular-figures height for smallcaps figures.

Yesterday I discussed the design and handling of the widths of figures sets, and the related widths of currency symbols, math operators and some other characters, with my Plantin students. Nowadays I prefer to make the width of the math operators identical to the width of the (non-fitted) tabular figures (in the early days with the Symbol-set insertion in Standard Encoded PS fonts, we used the width of the math signs in this set, which was 549 units IIRC).

When it comes to the width of currency symbols, at DTL we refer to Agfa Compugraphic’s Typeface Design Criteria Manual from 1989 still. If possible, we try to put the tabular-fitted old style figures on the same widths too.

(leave it me to get stuff off-topic ;-)

Ofir Shavit

Off-topics are welcome in my thered.

You can position the math ops anywhere you like so in this case we'll focus on adjustments relevant to what we're trying to examine in this experiment.

Watch this video clip to see how we automated the accented characters build-up.

And please tell me what are your expectations/guidelines for the spacing test...

Deleted Account

"You can position the math ops anywhere you like"

I know. Alignment issues are not solved until they are in the context of spacing, and size mastering, so you'll want to tell me that soon, what size is this particular style intended to be used at? OS figs are nice, but they are not part of the 'spec'. The rest of the comments you'll need to filter for design prefs, I'm mostly interested in the parameter networking through a basic, but Complete! glyph repertoire.

I don't want fractional excuses, if you persist in resisting the specification, then I will demand ©, ® and ™, £, ¢ and etc, until you have nagged yourself into a complete understanding of all the glyphs in the parametric network anyone could need to love your program on an introductory, but Complete! level.

You don't have to, of course, no one is holding a magnet to FontArk's sources.

Ofir Shavit

If it's relevant to the test I'll also add the Bopomofo Unicode block.

Fractions, anyone?

James Puckett

Fractions, anyone?

At this point I’d worry less about adding to the light fonts and more about the other extreme. It’s a lot easier to see stroke vertical/horizontal contrast in a bold or black weight than in something thin like this.

Ofir Shavit

Indeed, as the font weight increases the amount and intensity of the needed outline adjustments increases as well, but FontArk saves a tremendous amount of work and easing the process a lot... I'll demonstrate all of it when we'll get to that part in the demo, hopefully next week, but the principles are as follows...

- Increasing(/decreasing) the stroke's width is done to all the glyphs (300 and more) simultaneously with a slider bar.

- Increasing the stroke's width doesn't change the the size of the characters! (and the bearings) the external height and width of each character remains the same, that means that the width of the strokes is growing inwardly (and the skeletons shrinks wisely).

- When reaching heavy weights, first thing you'd like to do is widen some characters more some less, this is done quite easily with the Matrix (fluid grid). You can widen the entire char set at once and locally take care of groups and single characters.

- When the widths are fixed it is time to get in the Outline layer and locally adjust the contrast to each of the characters (excluding the accented characters which are automated according to BL character changes) from a very convenient starting point.

Thomas Phinney

I will second James' comment. I need to see a heavier weight to know what is working and what needs work.

“Increasing the stroke's width doesn't change the the size of the characters! (and the bearings) the external height and width of each character remains the same, that means that the width of the strokes is growing inwardly (and the skeletons shrinks wisely).”

Why would you do it that way? That means that the spacing is going to be bad for all possible weights except one, and that you are making the heavier weights more condensed and the lighter weights more extended, as far as normal type scaling is concerned.

Sure, the user should be able to make manual adjustments, but doing it the way you describe just makes it worse. It also puts some unreasonable limitations on how much weight can be added.

Ofir Shavit

We will test that font in any weight and width soon (well, almost any)

Thomas, you're right about the condensed/extended effect in that scaling mode. Increasing the skeleton's stoke enlarges the height and the width of the character with equal amount, that means that the aspect ratio of the character changes. Scaling it down to fit the original height and width cause a relative "condencment". I was compensating this effect by widening the font a bit, but we better fix the scaling calculations to fit the height and keep the aspect ratio for the width, Thanks.

we also have a normal scaling mode as well. you can see the difference of the two in this clip.

Deleted Account

Steady. Maintain course and speed.

"At this point I’d worry less about adding to the light fonts and more about the other extreme ...[] "to know what is working and what needs work."

With all due etc., extreme of what, and working where?

Once OS has his new favorite glyph repertoire, which I am recommending for the tools' sake, OS is chosing what size he is designing. No spacing, overshoot or even decisions on the division of the Em have even been discussed, much less nailed to the entire families stylistic drift. Then, again for the tool's sake, and increasingly for the design of the family, he can go in lots of directions, but I recommend size first, as the best behavior, because it informs width and weight completely, for all sizes.

Nice clip. I'd move the interface thingy in the lower left corner to the empty lower right corner, right below the interface thingy you're running mousey back and forth to from the first interface thingy, but I'm old and mousey is tired of such marathonic activities for no apparent reason other than to make the music last.;)

Ofir Shavit

David, what size are you talking about?
We have this font at this size, and this glyphs repertoire:



What's next? should I upload the font as font?

And I guess you're right, there's plenty of room on the right bottom, even when the rows are filled with gazillion glyphs

Ofir Shavit

Still not sure i'm getting you right, but let's say I'd like it to be used for poster designs.... Print, seen and looked at from 20m to 50cm, text size scaling from 16px to 300px with generous design flexibility.

Deleted Account

"What's next? should I upload the font as font?"

The glyphs that are missing are essential to the font. http://adobe-type-tools.github.io/adobe-latin-charsets/adobe-latin-1.html please.

Ofir Shavit

Adobe Latin 1 - We have them all.

Horses will break the fences soon...

Ofir Shavit

Here

Deleted Account

Great! (save the male ordinal who is out hunting?). Now can we see all these glyphs proofed between H's on zero leading?

Ofir Shavit

Is that what you mean??

I took the 'H', gave it zero bearings, and placed it between each glyph.
If you meant something else please clarify

Deleted Account

Good!
Take 1/3 of the H counter, i.e. from the inside of one stem to the inside of the other,
then 1/2 that third and put it on either side of H.
Then, take 1/2 left side of H and put it on either ride of O,
then put all the diagonals on zero (l.c. too).
repeat, take 1/3 of the n counter, and split that between side bearings,
Then, take 1/2 left side of n and put it on either ride of n,
look for the required n offset due to it's asymmetry,

Then apply the resulting side bearings to D and p. Look, and look again.
Then apply these values to all rounds, squares and diagons
Then look at this system throughout your intended range of size use,
and then look again and decide at what size(s) this spacing looks best...

And where the hell is that guy ordinal?

Jan Schmoeger

Ofir, I feel that you could benefit from all this homework. Seeing that you are flying already, please do not regard it as flak, just training ...

Ofir Shavit

I'll work with these instructions and come back for further clarifications if needed.

Are you looking for the MASCULINE ORDINAL INDICATOR?

Jan, I thank very much for this opportunity, and try to make the best of it in all directions, thanks for caring!

Jan Schmoeger

Thanks, Ofir. That one, btw, should be based on "o" (oh) rather than zero.
As in primo (he) and prima (she), that is gender sensitive. So a different, rounder shape.

Ofir Shavit

Got it, thanks... will O'ish it

Ofir Shavit

1/3 of the H counter - 380/3= 126.6
1/2 that third, on either side of H. - 63.3
1/2 left side of H on either ride of O - 63.3/2 = 31.6
all the diagonals on zero (l.c. too).
1/3 of the n counter - 300/3= 100 split to 60,40
1/2 left side of n and put it on either ride of n(o!) - 60/2=30

*Units are Fontark units

The system is looking good from 24px upwards (too dense downwards)

Questions:
- Shouldn't the right side of 'p' (left of 'q' etc') act like 'o'?
- Right side of 'r' is problematic, I treated it like a diagonal (i.e. zero bearing)
- 'Z' should be considered a diagonal or square?
- Right side of 'E' ?
- What about 'f' and 't'?
- Any special rule for 'space'?

Deleted Account

Has your proof of glyphs between H above been updated?

Ofir Shavit

Of course, it's your system's proofing

Ofir Shavit

The squares at the previous spacing had wider bearings (E, D, N, I, i...) The rounds and diagons we're pretty much similar to your's.

Deleted Account

"Of course, it's your system's proofing"

My system? No. My system says one will end up with 1/3 of the H counter and an uppercase stem thickness forming the middle of the HIH combination. If I wanted to shove things together 'till they sucked, I'd make vacuum cleaners or x-rated films.

Your H proof (hPHproof4-H.jpg), shows no such thing in the HIH combination, (attached), so my system is writhing in apparent pain on the turf. You had better help pick it up to prove it's faking before the referee, sadly for you, me again, comes over and gives you a yellow card.

"The system is looking good from 24px upwards (too dense downwards)"

So you'll be revising your choice of sizes at which this style is recommended?

"Questions:"
"- Shouldn't the right side of 'p' (left of 'q' etc') act like 'o'?"
Of course.

"- Right side of 'r' is problematic, I treated it like a diagonal (i.e. zero bearing)"
Of course.

"- 'Z' should be considered a diagonal or square?"
It's a dare.

"- Right side of 'E' ?" & "- What about 'f' and 't'?"

so, once you have a good set of constant spaces for HOV the exceptions fall into two categories: where one side is unique (E's right side), and where both sides are, like a two-story 'a' with a unique right baseline tail. These are viewed against the majority and values in the first style of a family such as this, and are decided by eye.

"- Any special rule for 'space'?"
Yes, and we argue about it. Somewhere between the set width of the 'i' and 1/2 of the em.

Ofir Shavit

@David
Well, I wasn't sure (as usual) I understood well all parts of the instructions
That's why I wrote down my calculations at the beginning of the previous post.
My strategy in such cases is to do what I understand and correct when needed (instead of nudging with endless questions) and by no means I had any intention to fake or anything of this kind.

First mistake I made is thinking that by "left side of H" you meant left bearing of H (63.3 that is 1/2 of 1/3 of 380 that is the H's counter)
My H's stem's width is 40 + half H's counter (380/2=)190 should have been 230 for the "left side H" instead of 63.3(left bearing).
Now this 230 should have been put on either 'ride' of O...
Unfortunately, there's no typography glossary out there (checked them all. twice) listing the term 'ride'
Which left me one of two options... 1. ride = side = bearing. 2. something with wild horses. I picked the first one.
That was somehow reasonable when the value was 63.3, but seems Not reasonable when the value is 230 which seems to me too wide for an O bearing.

Than please, what did you mean by 'ride'?

I was consistent with misunderstanding the 'left side' thing for the n as well.

But, all this goes to the O'o', and our main problem is with H'I'i'
Which leads me to the inevitable conclusion that there is another misunderstanding hiding somewhere.

At the first part you wrote:
"Then, take 1/2 left side of H and put it on either ride of O,"
At the second part you wrote:
"Then, take 1/2 left side of n and put it on either ride of n,"

I was assuming the first part is correct (O meant O), than the n in the second part should have been o instead of n,
Now It seems to me that the first part wasn't correct (O meant H) and the n in the second part meant straightforwardly, n.
And that makes much more sense, since 230 for the H's bearing would have solved the HiHl issue. and all the rest.

There's still a chance, that I've completely misunderstood your instructions, for such case here are the values of the spoken characters to make it easier for you to clear things up, if you will....
H - stems=40, counter=380
n - stems=40, counter=300

@Frode Thanks for your explanation about the whites inside and between the letters!

I'm not trying to convince Type designers to use FontArk. I'm trying to talk with type designers about tools and technical methods to design type. My preferred way to achieve this was (and still) to demonstrate HOW Fontark works and discuss how useful or not it is, for instance in this spacing via dolorosa we're going through, I would have been much happier to show you how easily (to my opinion) you can space and re-space etc' over 200 glyphs (I would show you this in 95 second demonstration) and let you (pros) see if it make sense and simplify things. If you'd like to you could space up a font, which is what you're good at, and I keep on developing Fontark... (Which is what I think I'm good at).

But, apparently Type designers are having hard time discriminating typography and typography-tools, i.e. need to see good typography to find any interest in the tool and methods used to create it. I have some criticism about that attitude and quite sure this way of looking at things might lead you to miss quite a lot, but it also has some good logic as well, and we could all benefit of it so i'm letting you lead on this one, and being patient, for there are much more type-tool-wise fascinating aspects to Fontark than the basic and quite covered and resolved spacing-managing i'm eager to demonstrate and discuss with you about.

So, I'll be waiting to any comment or clarification regarding the spacing issues before i'll fix it and move on.

*Brushing horses*

Jacques Le Bailly

But, apparently Type designers are having hard time discriminating typography and typography-tools, i.e. need to see good typography to find any interest in the tool and methods used to create it.

Maybe typedesigner are somewhat sceptical to new ways, but designing type is not about just tweeking stuff.

IMHO, when one is writing software, he/she should first try to understand the problem for which the software would offer a solution. What I am wondering about this thread and your argumentation, is that you have questions about some of the most basic elements in type design.

Type design is not just a collection of arches and straight lines. You try to convince us that FontArk could become a great way to spare some time and automate a lot of steps. But maybe you should first analyse what might be really important to type designers. Unless you want to create a tool that will fill the MyFonts library for coming years with arbitrary designs...