Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Best Of

  • Re: Berthold bullies competing font producers – report here when you’re hit by them

    Naw, this was Berthold and Monotype behavior years before the election.  
  • Re: Fun type draft

    Weights test 
  • Re: Berthold bullies competing font producers – report here when you’re hit by them

    I think for MyFonts, this is just a business decision. I expect they look at Popelka, consider the amount of money they are ever likely to make from it — it's an interesting design of obvious usefulness in some contexts, but probably not bestseller material —, and compare this to the financial cost of defending a potential trademark lawsuit. I can see how this doesn't look like a good investment from their perspective. I expect that if Berthold were challenging MyFonts over trademark of one of the long-term bestsellers, the calculation would be quite different.

    Andreas, I think you are wanting MyFonts to act on the basis of principle, but for a corporation trying to generate profit for shareholders there is no principle that ultimately won't be subject to this kind of calculation. This is not to say that corporations are utterly unprincipled, or that they never act according to principle: it's to say that their principles are owned.
  • Re: Opentype case & eszett

    Ray asked about ALL CAPS typefaces.

    What I'm saying is that a capitalized ß should default to "ẞ" and not "SS".

    Capitalisation is a character-level operation. So as explained elsewhere, the only way to do this is to use a custom casing method that performs this mapping, which is what is recommended for e.g. personal name databases in Germany. It's custom because it's not standard: the standard — in both the orthographic and technical implementation sense — is for ß to capitalise as SS. Might that change one day? Maybe, but in the meantime there's nothing to be done about it at the glyph level because capitalisation is not a glyph operation.
  • [OTVar] OpenType 1.8.1 released

    We've just published a new minor-version update of the OpenType spec: OpenType 1.8.1. This update was primarily aimed at refinements related to OpenType Font Variations, but there were a few non-variations-related technical changes, and we also used it as an opportunity for certain editorial improvements.

    The significant technical changes are the following:

    - Various technical corrections already noted as OT1.8 errata were incorporated.

    - In the 'fvar' table, the countSizePairs field was, in effect, a redundant versioning mechanism. This field has been changed to permanently reserved, and implementations are not expected to use it to determine how to read the table.

    - Also regarding the 'fvar' table, expected behaviour was spelled out for the cases of having axisCount = 0 (font is not treated as a variable font) and instanceCount = 0 (there is still one named instance).

    - In the MVAR table, the axisCount field in the header was redundant. This field has been changed to permanently reserved.

    - Cleanup of the CFF2 and CFF2 CharString chapters included correction of various technical errors, removal of the unused Boolean operand type, and other changes. (These chapters underwent a lot of revision, and I don't have exact details on how many changes might be considered technical changes.)

    - An additional field was added to the STAT table, now version 1.1. The 1.0 STAT table (without the additional field) is deprecated.

    - Also related to the STAT table, interpretation rules have be added for the case in which format 2 axis value tables for a given axis have overlapping ranges.

    - The version 5 OS/2 table added the usLowerOpticalPointSize and usUpperOpticalPointSize fields for families with optical size variants. This mechanism is now superseded by the STAT table. For now, these OS/2 fields are not yet deprecated, but use of the STAT table for this purpose is recommended, and we'd like to deprecate these OS/2 fields in the future.

    - In the discussion of the GETVARIATION instruction, "NPUSHB" was corrected to "NPUSHW".

    - In OT1.8, we introduced a convention of replacing a single Fixed table version number field with a pair of major/minor version fields. That was applied in OT1.8 only to tables already being touched; in OT1.8.1, this was extended across all tables for which it was possible. (For certain tables, such as 'post', minor numbering with Fixed has been done in a manner that doesn't really allow separating into separate major/minor fields.) In the future, we won't use Fixed for version numbers in any new tables.

    - In OT1.8, there were conflicting statements as to whether tables must start at 4-byte-aligned offsets. This is now consistently stated as a requirement.

    - Added OpenType Layout language system tags for Eastern Cham and Western Cham.


    A couple of things that is mostly editorial / marginally technical have to do with field names and data types. A handful of field names in various tables were changed for better consistency. A much broader change was in data type conventions:

    - For fields containing subtable offsets, the data types are now always Offset16 or Offset32.
    - The use of Windows data types CHAR, BYTE, SHORT, etc. has now been globally replaced with less ambiguous types: uint8, int8, uint16, int16, uint24, uint32, int32.
    - Removed FUNIT and GlyphID as data types. (FUNIT was not actually used anywhere as a data type, and GlyphID had been used only in a limited number of places but not in obvious places such as the 'cmap' and 'glyf' tables.)

    If you look at the change log, the majority of changes recorded are these data type changes. In terms of the number of pages touched, this will probably be one of the largest changes in the OpenType spec for a long time.
  • Re: Replace ß by smallcap eszett or smallcap ss?

    Jasper, I am not German but did ask a similar question some time ago in Typophile. And Frode, among others, did that here in TypeDrawers. The answer from German-speaking fellows and also specialists like John Hudson is do not include OT substitutions with Eszett and SS.

    Putting simply, Eszett shouldn't replace SS (or vice-versa) because they don't have exactly the same linguistic value. Besides this, there are differences between German and Swiss German.

    You can read details here, here and here (TD). And also here, here and here (TPHL). Technical information in these threads is highly valuable.
  • Re: Berthold bullies competing font producers – report here when you’re hit by them

    Another problem is that MyFonts does not vet any names. I recently had them take down 3 fonts for infringing on my registered trademarks. You would think that either MyFonts would check the USPTO database, or require the submitting designer to check before Accepting the submission.

  • Re: Berthold bullies competing font producers – report here when you’re hit by them

    How would MyFonts respond to a similar scenario if it happened to be a smaller foundry challenging a larger foundry?
    If the smaller foundry had a registered trademark and it found a larger foundry was infringing on that mark I'm sure MyFonts would act in a consistent way. The trouble I see is that most smaller foundries do not bother (for whatever reason) to register their trademarks with the USPTO and large foundries do. I'm a one-person operation and I register all of my trademarks with the USPTO.
  • Re: Technical Trivial Facts (.ttf)



    Santa realized that he was in a pickle because of eating too much reindeer on Thanksgiving.
  • Is this a font?

    Has anyone seen this cheery fellows been made into a working font or at least a full Basic Latin alphabet?