Howdy, Stranger!

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

John Hudson

About

Username
John Hudson
Joined
Visits
3,183
Last Active
Roles
Member, Type Person
Points
1,967
Posts
1,236
  • Re: Romanée – New Release?

    With regard to copyright and international law, if a country is a signatory to the Berne Convention, it has undertaken to provide to foreigners the same protections under copyright as it offers to its own citizens.
  • Re: Units per em

    There are two separate things here:

    1. Relationship of actual letter heights to the scaled body height. The reason for having (in a Latin script font) the actual ascender height plus descender depth be close to the UPM value of the font is to achieve fairly similar scaling of types at the same nominal point size, and hence within the typical contexts of typographic layout. Yes, it was possible to 'cast small on the body' even in metal type, and in digital type it is easy to make letters extend beyond the body height, but as soon as you start doing this you have to also start making adjustments in text size and linespacing values when switching otherwise similar fonts in apps.

    2. Management of different vertical metrics settings in OS/2 and hhea tables. If your typoAscender and typeDescender values are close to the actual ascender height and descender depth, and the latter are as described in (1), then rounding them such that they sum to the body height means that you can more easily manage the linespacing value in the typoLinegap independently from the body. Put another way: it allows you to think of the typoLinegap as leading, i.e. as something added to the body height. If you don't do it this way, then you're dividing the leading between the different vertical metrics. That's not technically wrong, but it isn't tidy.

    There are circumstances in which both (1) and (2) might be reasonably abandoned. There are also circumstances in which, after all the vertical metrics are set, the UPM value of the font gets changed. These things happen.
  • Re: Foundries Allowing Modification

    Shahab,

    Please help me understand this: If the concern is about the quality, so how about the time that there isn't a modified font and instead the designer did the modifications to the text written by the font (as in a typographic poster)? Are we going to be concerned about that as well? I mean I'm a graphic designer and it is safe to say that I never use a font without doing some changes to the text.

    You understand that there's a difference between doing typography and font manufacture?

    I'm not sure what kind of 'changes to the text' you are talking about here. If you mean, e.g. tracking or other adjustments to default spacing, or applying different colours, then you're simply doing the kind of things with fonts that fonts are designed to enable, you're doing typography. I might not like your typographic choices, but that's what the existence and the licensing of the font are created for.

    If you're talking about converting text to outlines and modifying the appearance of the text by editing those outlines, then you're creating a piece of modified text, not a modified font. Again, I might not like what you do to the text, but unless I'm going to explicitly prohibit such a use in the license agreement, I accept that when you convert the text to outlines you are no longer dealing with my font — indeed no longer deatling with text — but with an image of text.

    If, on the other hand, you decompile my font in an editing tool, make modifications to some glyphs, maybe add some glyphs, and adjust some spacing, there are a lot of things in that process that can affect the quality not only of the things you are consciously modifying but elsewhere in the functionality of the font, as unintended consequences. When decompiling a font and making a new, derivative font, you're not editing text or an image of text that you made, but are changing the thing that I made. So I think I have a right to be concerned about the quality of that thing, for its own sake.

    [Note that this is not to say that we're going to disallow modification. As I wrote above, this is something we're considering as we draft our commercial EULA. But my inclination is that I'd like to know who is doing what to the things that I make, so that I can have some input of making modified, derivative fonts as good as they can be.]
  • Re: Foundries Allowing Modification

    We're still considering whether or under what conditions to permit modification in our commercial license. What I've done in the past, in some of our no-fee no-commercial-use licenses, e.g. for the SBL fonts, is to include a requirement that any modified fonts be sent to us, and we reserve the right to include such modifications in future versions of the font. The context there is fonts for specialist scholarship, recognising that modifications, especially extensions, might be useful for others in the user community. But I think there's a more general point to be made about who owns derivative works, and the right to exploit those commercially. Modified fonts are covered, as derivative works, by the copyright of the original, and by the terms of the original license agreement. That is, no matter how substantially modified, the fonts belong to the original copyright holder.

    I've seen modified versions of fonts used in branding, in which changes to a few common letter shapes create a distinctive typographic look and feel without the expense of commissioning a whole custom typeface. My understanding is that there is nothing in that case to prevent the original font foundry from releasing their own version of that modified font — even taking that modified font as is and releasing it, or licensing it to another customer, even one in competition with the branding agency's client — and thereby undermining the value of the branding exercise.
  • Re: I trained a neural network to kern a font (mostly)

    Unless a license explicitly prohibits analysing the kerning data, where's the infringement? Collecting and analysing kerning data doesn't even necessarily involve decompiling the font, since it can be collected from text output. Kern values, as implemented in the kern table and typical GPOS pair adjustment lookups, are data, which typically has minimal copyright protection. In the US, for instance, I believe it is still the case that data itself is not protected by copyright, only particular selections or arrangements of data. So a kern table might be protected as part of the font software, but the kern values in that table would not be. [Usual caveat: I am not a lawyer.]