Where is Console.app output?

Tosche · July 1, 2021, 9:32pm

I’m struggling with Python-related crashes and want to find out the cause (it’s especially setKerning functions that give me instant crashes). I set the ‘Use system console for output’ preference but I don’t see the outputs. Where in Console do I need to look?

FlorianPircher · July 1, 2021, 9:41pm

Not sure about Console.app, but when running Glyphs from a Terminal you should be able to see the output.

Run the following line:

/Applications/Glyphs\ 3.app/Contents/MacOS/Glyphs\ 3

like so:

Tosche · July 1, 2021, 10:03pm

Thanks. I could see the Python output that way but couldn’t catch any error from the function.
I remember that Preference option working in the past, but not anymore I guess? And shouldn’t the option be rewritten if it uses Terminal instead of Console?

(Also I still do not like the fact that I now have to juggle around glyph names and IDs in G3 kerning, whereas everything was glyph names before.)

GeorgSeifert · July 2, 2021, 5:18am

The trace back might be to late and the app is already gone in your case. Can you send me the script that I can see if I can improve the crashing behavior?

And I don’t remember changing the kerning API to not accept names. What functions do you use?

Tosche · July 2, 2021, 12:24pm

Here’s the script. You need to test with a file that have Greek and Cyrillic who belong to separate kerning groups. Line 164 causes the crash. Copy Kerning to Greek & Cyrillic.py.zip (3.4 KB)

In my case, a lot of kerning-related scripts were broken in G3, and the cause were all related to single glyphs being communicated in id instead of names. Maybe internally they have always been glyph id, but I never needed to see that before. Even GSFont.kerning output were all name-based before but id-based now, which I use often. Other functions are setKerning functions.

Actually, the ids even show up in regular UI. The screenshot is taken in the latest cutting edge version and new file.

GeorgSeifert · July 6, 2021, 9:21pm

When the IDs show up in the kerning window, that means it couldn’t find a glyph with that ID. I’ll have a look at the script.

Tosche · July 7, 2021, 1:18pm

Thanks. In the case of this screenshot, the kerning value was entered via standard keyboard shortcut.

This script is still not updated for the G3 behaviour for example, and worked in G2. Where single glyphs are used in kerning data, it’s exclusively exchanged in glyph names. I could read kerning data and applying the value to some other pairs without worrying about whether the pair members were glyph names or keys.

github.com

Tosche/Glyphs-Scripts/blob/master/Metrics & Kerning/Copy Kerning to Greek & Cyrillic.py

#MenuTitle: Copy Kerning to Greek & Cyrillic...
# -*- coding: utf-8 -*-
from __future__ import print_function, division, unicode_literals
__doc__="""
(GUI) Copies your Latin kerning to the common shapes of Greek and Cyrillic, including small caps, using predefined dictionary. Exceptions and absent glyphs are skipped. It's best used after finishing Latin kerning and before starting Cyrillic and Greek.
"""

import vanilla
import GlyphsApp

#Stores a Latin glyph name as key and G/C glyph as unicode value, because glyph name may differ
Grk = {"A": "0391", "B": "0392", "E": "0395", "H": "0397", "I": "0399", "K": "039A", "M": "039C", "N": "039D", "O": "039F", "P": "03A1", "T": "03A4", "X": "03A7", "Y": "03A5", "Z": "0396", "o": "03BF"}

CyrUC = {"A": "0410", "B": "0412", "C": "0421", "E": "0415", "H": "041D", "I": "0406", "J": "0408", "K": "041A", "M": "041C", "O": "041E", "P": "0420", "S": "0405", "T": "0422", "W": "051C", "X": "0425", "Y": "04AE", "Schwa": "04D8"}

CyrLCNormal = {"a": "0430", "abreve": "04D1", "adieresis": "04D3", "e": "0435", "egrave": "0450", "edieresis": "0451", "o": "043E", "p": "0440", "c": "0441", "y": "0443", "ydieresis": "04F1", "x": "0445", "s": "0455", "h": "04BB", "l": "04CF", "i": "0456", "idieresis": "0457", "j": "0458", "w": "051D", "schwa": "04D9", "v": "04AF"}

CyrLCCursive = {"a": "0430", "abreve": "04D1", "adieresis": "04D3", "e": "0435", "egrave": "0450", "edieresis": "0451", "ebreve": "04D7", "u": "0438", "ubreve": "0439", "ugrave": "045D", "o": "043E", "n": "043F", "p": "0440", "c": "0441", "m": "0442", "y": "0443", "ydieresis": "04F1", "x": "0445", "s": "0455", "h": "04BB", "l": "04CF", "idieresis": "0457", "i": "0456", "j": "0458", "w": "051D", "schwa": "04D9"}

This file has been truncated. show original

(By the way, I would suggest GSGlyph.left/rightKerningGroup to add MMK prefixes. It’s something I always need to add, and it makes more sense to me to include them than otherwise.)

GeorgSeifert · July 7, 2021, 1:37pm

There is a separate property that gives the full kerning class name (including the MM_K…): glyph.leftKerningGroupId() (fixed)

Tosche · July 7, 2021, 1:39pm

Thanks. That part is solved then.

Tosche · July 14, 2021, 5:38pm

I tried different kerning dictionaries and I noticed GSFont.kerningDictForDirection_() prints single glyphs in names, not IDs (that’s how I remember everything to be in G2 and I prefer it this way). Others print IDs on the other hand: .kerning, .kerningLTR(), kerningForDirection_()
@GeorgSeifert , what’s your thoughts on this? Do you want to unify or vary the formats? Can you keep at least one way to print glyph names?

(EDIT 1)
I also noticed that removeKerningForFontMasterID_LeftKey_RightKey_() only accepts glyph IDs (or group names) but doesn’t accept names. (removeKerningForPair() is the opposite)

(EDIT 2)
And to demonstrate another ID/name oddity, if I run the code below, the value in the kerning window shows the value in ID instead (and the method wouldn’t accept glyph ID as input).

A = Glyphs.font.glyphs["A"].name
Glyphs.font.setKerningForPair(m.id, A,A,-20)

Tosche · September 18, 2021, 5:25pm

What is the argument for RTL kerning in Glyphs.font.kerningDictForDirection_()? I have tried 0–255 but none of them seems to be it. 0 and 1 seem to be identical, and the rest is a miss.
(I don’t want to use kerningRTL since it reports glyph IDs)

The real issue is that I have a Latin-Arabic file whose kerning data is all mixed up in LTR table (made in G2) and want to make it G3-compatible. Is there already an easy ready-made solution for that?

FlorianPircher · September 18, 2021, 6:28pm

RTL should be 2. See GSWritingDirection. In Python, you can use the constants defined in the Python docs:

print(RTL)
# => 2

Tosche · September 18, 2021, 7:13pm

Thanks. It’s strange, nothing is reported even though I do have pairs.

FlorianPircher · September 18, 2021, 7:51pm

Hm, works for me. Could you send your file to the support email address?

Tosche · September 18, 2021, 8:03pm

Ah never mind, it works. (maybe not right after I run a script)