After the first sessions on the MAD-fac

Glyphs
1

In the period we did give the first introduction to Glyphs in our college, we have encountered some issues that I want to post here. I think students are going to encounter these things more than once.

1)) Working with images

On our school, we have a central Apple-server where some working-files are stored.
On that server none of us is an admin. Ann Bessemans (teacher) can read and write, the students are guests and they can only read the files there.
When directly importing images from the server, Glyphs doesn’t take that. Dragging from the Finder to Glyphs does nothing. Importing the file with the menu does show the image, but the students couldn’t rescale an image imported on this way.

I know this trouble is server-side. But I would suggest to make an option in the preferences to ‘let Glyphs manage imported images.’ Below this option there could be an explanation: “Glyphs will copy images that are not in the same folder as the Glyphs file to that specific location.” (or in an sub-folder would even be better.)

2)) Program bugs

After working for a while, some students couldn’t zoom in anymore (Command and plus), or couldn’t scroll with the trackpad etc. Or in an extreme case, when switching to an open tab did not refresh its content; the font overview remains visible. After a program restart it was always solved. This could also be related to opening files from a server of from within a zip-file, but I haven’t had the change to find this out.

3)) Grid systems

When entering a new value in the ‘Grid Spacing’ or ‘Subdivision’ of the font info, one has first to hit the enter button and then go to the font-window before changes are visible. When not doing so it is easy to think Glyphs hasn’t take the new value.

Is it possible to add an button next to the two fields ‘Grid Spacing’ and ‘Subdivision’ to directly update? So one can remain in the Font Info and see in the background in the other window if the new grid is correct?

4)) handle addition:

The way to add an handle in Glyphs is to alt-click on a path. Most programs (like Illustrator) support this also with the node. So can an alt-click on a node make the handles?

5)) Vertical/horizontal handles

Dragging a handle when holding the shift key places that handle exactly horizontal/vertical. But when setting a very rough grid, like Grid Spacing=100, Glyphs doesn’t take that shift-key, because the grid isn’t allowing for vertical/horizontal placing. (surely when there is already drawn before the grid is changed: nodes can be between grid lines.)

I think the shift-drag of a handle should override the grid system?

6)) OpenType Features

I have always learned the order of the OpenType statements are important:
You write the long statements first, and then the shorter statements:

sub f’ f’ i’ by f_f_i;
sub f’ f’ by f_f;

When reverting this code, the first substitution has taken place, and the f’ f’ i’ will never appear because f’ f’ can’t be there anymore:

sub f’ f’ by f_f;
sub f’ f’ i’ by f_f_i;

However, when not working with tick marks, it contradictory does work. The students saw this and I couldn’t explain:

sub f f by f_f;
sub f f i by f_f_i;

My best bet is the manner of how the two codes are stored in the font are different? I can’t directly explain it otherwise. Is there a simple explanation for this contradiction?

——
Maaren

2

Thank you for your input. We will discuss your suggestions. Two answers I can give straight away:

  1. no. Because it causes people to draw bad paths. AI drawings are known for their zero handles, for instance. While vector quality may be not an issue in illustration, it is a big issue in type design.

  2. first, only subruns in contextual lookups need tickmarks. Plain ligature subs do not have ’ marks. And secondly, the reason why the ‘wrong’ order works in this case, is that the AFDKO compiler can figure this out by itself and reorder the lines as needed. In most cases, at least.

3
  1. no. If you want straight handles, you need a finer grid. If you want a rough grid, you cannot have straight handles diagonally. The point of the grid is that everything conforms to it.
4

  1. can you open a new file, add an image from the server, save it and send me the file?

  2. this is a known issue. It has nothing to do with the server. What version do you have (exact version number)?

5

Thanks again for all the replies.

  1. I have sent such a file to Glyphs-Info.

  2. The students had OS X Mountain Lion or OS X Mavericks. The version of Glyphs was the latest stable version: 1.4.3.

  3. Clear. But when in Glyphs the handles were placed on a distance from the node (like it is done as in alt-click on a path) I think it is possible.

  4. Fully agree. But sometimes, there is an exception on the grid. It just did look like Glyphs ignored the shift-key, because there was no difference between holding it or not. It did take a while before I understood the problem was the grid.

  5. Got it. I knew the tick mark was not always necessary, but I didn’t know the AFDKO compiler could rearrange statements by itself. Thanks for clearing out!

6
Sorry, I don't accept this. The grid is not an end in itself.

To discuss 5), we should first think about why the user would use a coarser grid in the first place, to find out what the point of the grid is.

Of course, there are several reasons for using a coarser grid. I could think of:

a) preventing myself from senseless fiddling with imperceivable details
b) allowing for rounding-error-free interpolation (e.g. in case the semibold is precisely 50/50 in-between, using 500 UPM for design).
c) possibly reduced file size. This depends on the design and the inner workings of the file format in question.

For a), which is my main reason, allowing BCPs off the grid would allow for smoother connections while not much impeding the purpose of self-restriction in terms of contour position.

In this sense, I support the request for a mode in which the grid is not applied to BCPs

7
Simply calling zero handles bad quality, or their use bad practice, is without a rational foundation, as far as I can see. To some designers they look totally wrong, others use them a lot (including me). Any software that processes font data should be able to deal with zero handles in a graceful way and allow designers to use them.
8

We had the discussion before. And I still disagree, because I think these arguments are rational: There are problems with some rasterisers, and there are problems with the further processing of paths, e.g., vector conversion, path offsetting, corner rounding, etc. Technically speaking, BCPs approximately mark the thirds of the curve. The, zero-handles are inefficient. And while mainstream rasterisers have become more tolerant in recent years, a software processing fonts (on the fly) may still assume that you have properly placed BCPs.

Please note that if you want zero-handles in your final font file, Glyphs does not prevent you from doing that. So it is at your discretion anyway. I just don’t recommend it, for the reasons stated above.

However, designing with zero-handles is fine. That purpose is the exact reason why I wrote the Fix Zero Handles plugin. It can ‘fix’ your zero-handles at export. That is a viable solution that satisfies both the need of the designer who wants to use zero-handles in the design process, and of software that doesn’t handle them well.

9
I wrote a script that will realign handles off the grid, but I didn't publish it yet because it is a little difficult to use (it only processes the currently open layer because it calls a select tool method), and there are some special cases it does not handle that well yet.

But for exporting, you would still need to make sure you have a finer grid or higher subdivision. Or a Grid Spacing custom parameter in the instance.