SOLVED surfing through font.info attributes issue



  • Hi you all!
    I'm having trouble in localizing stuff in font info based on opentype spec. I'm trying to write some fixing scripts for a typeface where there was a mistake in item with ID 4 (Full font name) in name records. I know that RInfo object uses this naming as attributes, and this is how I could potentially edit item with ID 4:

    list of attrs in the font info

    But even if most of the stuff in this list has rather a self-explanatory naming, I'm not always sure how to address specific records.

    Is there any list online where I could easily say that record ID4 is "this and that" attribute of RInfo?

    Best,
    Rafał



  • Thanks @gferreira!



  • hello @RafaŁ-Buchner,

    …nameID 1 issue. Font Bakery says it should be filled with the same text as in the family name.

    this is not correct…

    here is what the OpenType specification says about name ID 1:

    Font Family name. The Font Family name is used in combination with Font Subfamily name (name ID 2), and should be shared among at most four fonts that differ only in weight or style (as described below).

    so, if you are creating style-linked sub-families, name ID 1 will not be the same as the family name.

    see Setting font family names



  • @gferreira Tanks for the links! those are very helpful.

    the reason why I asked for this is that my client uses fontbakery for checking if everything is ok. It gives me a lot of headaches.
    One of the most irritating ones is the nameID 1 issue. Font Bakery says it should be filled with the same text as in the family name. But somehow makeotf and fontmake include there also style name (something like "Helvetica Medium") by default.

    And now I don't have a clue which (makeotf, fontmake or fontbakery) way is the proper one. When I read the spec, I "feel" that font bakery has a good idea about how it should look like. But it is more of the guess.

    Very surprising is a fact that if I'm trying to overwrite ID 1 in name records and then export the otf with the built-in RF makeotf, the engine is overwriting my choice anyway in otf file.
    It is a bit counter-intuitive and I'm not sure if it is intended by you and Frederik.

    (here is the code that I'm using for overwriting the records)

    f = CurrentFont()
    familyName = 'FamilyName'
    
    replaced = False
    if f.info.openTypeNameRecords is None:
        f.info.openTypeNameRecords = []
    for k in f.info.openTypeNameRecords:
        if k['nameID'] == 1:
    
            k['string'] = str(f.info.familyName)
            replaced = True
            
    if not replaced:
        print('added')
        f.info.openTypeNameRecords += [
                {'nameID': 1, 'platformID': 1, 'encodingID': 0, 'languageID': 0, 'string': familyName},
                {'nameID': 1, 'platformID': 3, 'encodingID': 1, 'languageID': 1033, 'string': familyName}
            ]
    else:
        print('replaced')
    print(f.info.openTypeNameRecords)
        
    

    When I'm trying to export the same ufo, with overwritten ID 1, using fontmake in the terminal, everything works fine (more or less at least when it comes to this issue).

    Maybe my guess that this entry should contain only family name is bad?



  • hello @RafaŁ-Buchner,

    the fallback values for font info attributes are computed by ufo2fdk.fontInfoData – see also the notes in Setting font infos. I think name ID 4 is generated automatically by makeotf though.

    if you can’t fix it indirectly, you can try generating the fonts and changing the name ID 4 directly using fontTools.

    hope this helps!

    edit: see How to add name table entries with FontTools?



  • By the way,
    I'm curious how name record with nameID 4 is being generated when RF exports .otf file?
    I'm having the issue that it takes the family name and connects it with the style name. I'm assuming that maybe while I was working on the naming in my typeface I have made mistake and put the wrong name in some text box?