Fonts allowed in a packaged file

[R C-R]

Thanks for the info about determining restrictions, but it seems that all the answers reference Windows. Is there anything specific to Macs about this?

[MikeW]

18 minutes ago, R C-R said:

Thanks for the info about determining restrictions, but it seems that all the answers reference Windows. Is there anything specific to Macs about this?

The same information can be found on Adobe's and Apple's developer sites. It's just the specifications for fonts. The information is platform agnostic. 

[Wosven]

Nearly a decade ago, when switching from QXP on OS X to ID on Windows, we had a problem with a PDF that didn't even end up in the "Error" folder of Pitstop, but there wasn't any usual error in the document preventing it to pass the Pitstop test.

We had to connect to Piststop server and check the logs, to learn than the file was rejected since using an OS X system font. It wasn't one of the usual system fonts (like Geneva, or other fonts with capitals' names), but one of the extra font family shipped with the OS at the time.

If this happened with this old Pitstop server, I'm wondering how printers manage such problems today, and if they need to convert the fonts to curves when it happens (if they are embeddable). But talking with this printer teach us that she was dreading when we send her QXD's PDF, since they always needed to work on/modify the files. (At least with QXP versions prior to 8.5).

 

This kind of problems isn't new, and if other apps can give an easier way to manage those restrictions, Affinity apps certainly can.

 

  

 

19 hours ago, R C-R said:

The obvious solution for teachers & students is to avoid using any fonts or other resources encumbered by EULA or copyright restrictions for coursework.

Perhaps you can't remember the time when computers were sparse, only few in a room for all the school, with limited access and options, and you really learn your job once you had a job... I wouldn't mind being a student today and having my own computer, possibly a Creative Cloud subscription for education, and access to a variety of fonts I can simply activate.

It's always a pleasure while in the commuter train, to see students opening their computer or tablet and working on their school or personal projects... (most of the time it's drawings, not DTP). We did the same, but with a booklet and a pen.

 

Edited March 5, 2022 by Wosven
QXP the app, instead of QXD(ocument) the extension

[MikeW]

4 hours ago, Wosven said:

Nearly a decade ago, when switching from QXD on OS X to ID on Windows, ...

If this happened with this old Pitstop server, I'm wondering how printers manage such problems today, and if they need to convert the fonts to curves when it happens (if they are embeddable). ...

It's QXP, btw. QXD was the file extension for old versions of QXP files...

If what you are suggesting is to convert cloud fonts to curves in an APub packaged file, it wouldn't be a good thing.

Another off-topic btw...we/I only ever had a single page in a pdf that refused to play nice. That was an ID-generated pdf.

[Wosven]

1 minute ago, MikeW said:

It's QXP, btw. QXD was the file extension for old versions of QXP files...

Completely right, I'm too used to write ID. It was simply XPress, and XP in the old days, and today QXP.

 

3 minutes ago, MikeW said:

If what you are suggesting is to convert cloud fonts to curves in an APub packaged file, it wouldn't be a good thing.

Certainly not, that why I didn't understood people suggesting this in the first place.

 

I was just wondering, since I don't have those old PDF — or they are buried somewhere and I don't want to search and test —, how printers managed those files, and the kind of errors they produced (we didn't used Pitstop in those days). It's simply curiosity, that's not really important, but if we had known, we would have tried to do better.

11 minutes ago, MikeW said:

Another off-topic btw...we/I only ever had a single page in a pdf that refused to play nice. That was an ID-generated pdf.

Usually, most problems came from us, users forgetting to update links, or using low resolution images.
The restricted font happened only once, since we were careful afterward.

Or today, when clients don't look at the specification we send them, but it's different.

Some problems, needing special workflow for converting the PDF, are due to exotic PDF libraries, probably not set properly in the original apps, or without possibility to modify the settings finely. But those are mainly legal ads or classified ads send to us. 
With small ads containing too many errors, flattening the files to raster image is the faster solution.

[R C-R]

9 hours ago, MikeW said:

The same information can be found on Adobe's and Apple's developer sites. It's just the specifications for fonts. The information is platform agnostic. 

Maybe I am not making myself clear about this. I want to know how APub on my Mac determines the restrictions. I don't think it is accessing these websites!

[Wosven]

6 minutes ago, R C-R said:

I want to know how APub on my Mac determines the restrictions.

Simply disabling copy of fonts not in the usual folders, for example. Usual directories meaning the font folder, the current package folder and the "Document fonts" folder of any archived ID file*.

 

* If APub is able to read and use those fonts when opening an IDML file, if not, they need to be manually installed, and the fonts not copied.

Edited March 5, 2022 by Wosven
Added comment

[MikeW]

10 minutes ago, R C-R said:

Maybe I am not making myself clear about this. I want to know how APub on my Mac determines the restrictions. I don't think it is accessing these websites!

The OS API, the same as Windows, Linux etc. The font subsystem can/does access that information. Calls to that from an application are returned. Then the application acts on that information. 

An exception to that method is Adobe applications. They have their own font subsystem that does not rely on the OS.

[kenmcd]

10 hours ago, R C-R said:

Thanks for the info about determining restrictions, but it seems that all the answers reference Windows. Is there anything specific to Macs about this?

The reference linked is not about Windows. Microsoft is simply the keeper of the official OpenType specs.

Note: the Apple font reference site is not the official specs, and has substantial non-standard differences.

[kenmcd]

24 minutes ago, R C-R said:

Maybe I am not making myself clear about this. I want to know how APub on my Mac determines the restrictions.

What part about this are you not getting? It has been explained 2-3 times now that apps read the embedding settings in the fonts.

[MikeW]

36 minutes ago, Wosven said:

... I was just wondering, since I don't have those old PDF — or they are buried somewhere and I don't want to search and test —, how printers managed those files, and the kind of errors they produced (we didn't used Pitstop in those days). It's simply curiosity, that's not really important, but if we had known, we would have tried to do better.

... 

With small ads containing too many errors, flattening the files to raster image is the faster solution.

Before PDFs, we received ads, etc., generally as high-res TIFFs. Sometimes, we were given the Postscript files directly, versus the applications files, and if there were issues we could fix, we edited the .ps files. That typically was faster than using couriers to expedite obtaining the application files. "Bad" PDFs were always rasterized in PS as you mention. These days, I can often fix PDFs, but still rasterize if the first time attempting to fix doesn't take.

[R C-R]

1 hour ago, LibreTraining said:

What part about this are you not getting? It has been explained 2-3 times now that apps read the embedding settings in the fonts.

It seems that there have been several answers but they are not all the same. It can't just be what folders they are or are not in. If it is an OS level API, then I would like to know how I can access it on my Mac, particularly to see what the different restriction bits might be, & if that info can be returned to APub so we see more than just "Restricted. in that app" I think that would be a good feature request if it is feasible.

[R C-R]

7 hours ago, Wosven said:

21 hours ago, R C-R said:

The obvious solution for teachers & students is to avoid using any fonts or other resources encumbered by EULA or copyright restrictions for coursework.

Perhaps you can't remember the time when computers were sparse, only few in a room for all the school, with limited access and options, and you really learn your job once you had a job... I wouldn't mind being a student today and having my own computer, possibly a Creative Cloud subscription for education, and access to a variety of fonts I can simply activate.

I am sorry but I do not see what this has to do with what I proposed about either avoiding the use of restricted fonts in coursework or teaching students about those restrictions if you do want students to be able to use those items for coursework.

[MikeW]

16 hours ago, MikeW said:

It would be interesting, to me, to use a cloud font with the fsType bit set to embeddable whether Serif still flags it as Restricted. That would then seem to indicate Serif knows cloud fonts should not be packaged. 

Hah, quoting myself.

Serif is (at least in part) determining that a font is to be listed as Restricted based upon a non-standard, hidden font folder. That a font is Installable (no embedding restrictions, the most permissive fsType bit set) has no bearing as to it being marked as Restricted in Apub's packaging process.

The font below is part of Monotypes "Christmas font pack," available on the Windows store. These MS Store fonts are installed in a hidden folder structure:

C:\Program Files\WindowsApps folder.
Then the "package name". In my case:
MonotypeImagingInc.MonotypeChristmasFontPack_1.0.0.0_neutral__776bkhgfrgb7p

After one takes ownership of that folder (it's not enough to view hidden files/folders), and look at one of the font's properties:

You can see it is Installable.

Yet, in APub, the warning is still:

Restricted here is simply due to the font's location.

This is what is being used with the CC cloud fonts too.

So Serif, while being dumb about the font's fsType bit as regards "cloud" fonts, isn't even taking the time to view/read the fsType bit. Serif is using the hidden status. This means Serif "knows," at least as regards Adobe cloud fonts, what they should do with them: Not Package them!

But their code still needs tweaked. The font I used above should absolutely not be notated as Restricted.

Edit: The other means for Serif to even know where the font is actually located is via the Registry...

 

 

[R C-R]

7 minutes ago, MikeW said:

The font below is part of Monotypes "Christmas font pack," available on the Windows store.
{...}

The font I used above should absolutely not be notated as Restricted.

Once again, I have to admit I am confused about what this means. If that font should not be notated as "Restricted," does that mean it should be OK for you to include it in an *.afpackage & distribute that to other APub users, for example someone like me who has no access to the Windows Store, no idea of what the EULA for that font permits, & could not get my own copy of it from that store?

[LondonSquirrel]

21 hours ago, Old Bruce said:

Then you cannot use the software. To use the software you have to agree to the EULA.

That is very debatable to say the least. As in the examples I have given, in a corporate environment I have no idea if the software is licensed or not, nor what that license is, or if somebody gives me a computer already set up for use. They may well have broken the EULA as they presumably clicked the 'I agree' button, but I did not.

[LondonSquirrel]

21 hours ago, R C-R said:

Just to be clear about this, are you saying that wherever an EULA is "basically" (whatever that means) considered part of a contract, if you are not explicitly a party to it, then you personally have no legal obligation to abide by its terms?

An EULA is a contract. This is different to copyright, which is covered by imposed laws. 

If you are not party to a contract you are not obliged to obey any part of it. Think about it: your neighbour buys a computer and clicks the 'I agree' button. What affect does that have on you? None whatsoever.

[MikeW]

4 minutes ago, R C-R said:

Once again, I have to admit I am confused about what this means. If that font should not be notated as "Restricted," does that mean it should be OK for you to include it in an *.afpackage & distribute that to other APub users, for example someone like me who has no access to the Windows Store, no idea of what the EULA for that font permits, & could not get my own copy of it from that store?

That font should not be marked as Restricted.

Yes, it would be permissible to be packaged. As long as I am the only user bof that font in that package. But, more below...

No, it would not be permissible to share the font to another user, either as a font file nor as an APub packaged file. The only exception that one wouldn't get into trouble sharing the font/package file if sending to a print service. Still, that technically has never been permitted from many font foundries but has historically not been something font foundries has sued over. As for non-cloud fonts from Adobe, it has been permitted--but never to another, regular application user. However, the Adobe Cloud fonts as per the original point of this thread are explicitly forbidden to be handed over to even a print service, which is why Adobe/QXP will not package them.

The Monotype EULA (for any of their fonts) is fairly difficult to actually find. While they point to their website to read the full EULA, I couldn't find it. Inside the font itself, the brief license statement is:

This font software is the property of Monotype Imaging Inc., or one of its affiliated entities (collectively, Monotype) and its use by you is covered under the terms of a license agreement. You have obtained this font software either directly from Monotype or together with software distributed by one of the licensees of Monotype. This software is a valuable asset of Monotype. Unless you have entered into a specific license agreement granting you additional rights, your use of this software is limited by the terms of the actual license agreement you have entered into with Monotype. You may not copy or distribute this software. If you have any questions concerning your rights you should review the license agreement you received with the software. You can learn more about Monotype here: www.monotype.com

Perhaps the pertinent part is now bolded above. However, what has historically been permitted are backups. Which, aside from sharing a package, the main point of packaging has been to collect all required assets (images, fonts, etc.) in a central folder structure for archival purposes. Packaging also has other utility, too. But sharing a package's assets isn't really one of them--with exceptions, like sending to a print service, to aid a software vendor in troubleshooting, etc.

[walt.farrell]

16 minutes ago, MikeW said:

No, it would not be permissible to share the font to another user, either as a font file nor as an APub packaged file.

That confuses me. 

It should be acceptable according to the definition of the fsType settings we've been pointed to earlier, which say for Installable: (with my emphasis)

Quote

Installable embedding: the font may be embedded, and may be permanently installed for use on a remote systems, or for use by other users. The user of the remote system acquires the identical rights, obligations and licenses for that font as the original purchaser of the font, and is subject to the same end-user license agreement, copyright, design patent, and/or trademark as was the original purchaser.

And someone in the related Feature Request topic suggested when I asked for both fsType and the license to be displayed that fsType is sufficient.

[Old Bruce]

12 minutes ago, MikeW said:

... However, what has historically been permitted are backups. Which, aside from sharing a package, the main point of packaging has been to collect all required assets (images, fonts, etc.) in a central folder structure for archival purposes. Packaging also has other utility, too. But sharing a package's assets isn't really one of them--with exceptions, like sending to a print service, to aid a software vendor in troubleshooting, etc.

This I agree with. And this is why I think Affinity/Serif has not given us the ability to break the law/contract. We have been given an easy method to backup our projects.

Still just my 2¢, as I don't have a Cloud Font license.

[R C-R]

11 minutes ago, MikeW said:

Yes, it would be permissible to be packaged. As long as I am the only user bof that font in that package.

But how could APub possibly know that you would be the only user? It seems to me that in the Package Document > Fonts window "Restricted" just means it should not be included in a package that is distributed to other users.

18 minutes ago, MikeW said:

The Monotype EULA (for any of their fonts) is fairly difficult to actually find.

It seems to be hard to find for a great many fonts, including ones from both Monotype & Linotype that are installed with the macOS on my Mac.

23 minutes ago, MikeW said:

Perhaps the pertinent part is now bolded above. However, what has historically been permitted are backups. Which, aside from sharing a package, the main point of packaging has been to collect all required assets (images, fonts, etc.) in a central folder structure for archival purposes. Packaging also has other utility, too. But sharing a package's assets isn't really one of them--with exceptions, like sending to a print service, to aid a software vendor in troubleshooting, etc.

Given the various exceptions; how difficult it can often be just to find the terms; & the often dense legal language they are written in, is it any wonder that there is so much confusing about this?

[MikeW]

9 minutes ago, walt.farrell said:

That confuses me. 

It should be acceptable according to the definition of the fsType settings we've been pointed to earlier, which say for Installable: (with my emphasis)

And someone in the related Feature Request topic suggested when I asked for both fsType and the license to be displayed that fsType is sufficient.

And yet, the devil is in the details as regards how the permissions are/can be used. That control of the installable designation in that particular font applies to app-embedding and/or an app's installation as required for the app (which is permitted by the license), but the Monotype license expressly forbids the sharing of that font as a usable, physical entity.

Clear as mud, isn't it?

This, font licensing, is what keeps IP lawyers busy.

[R C-R]

6 minutes ago, Old Bruce said:

This I agree with. And this is why I think Affinity/Serif has not given us the ability to break the law/contract. We have been given an easy method to backup our projects.

But that same ability makes it possible to share these package files with other users, which from what @MikeWwrote seems to be a violation of the licensing terms.

[Old Bruce]

Back in the bad old days it was simple in that copying a font meant a good chance of lead poisoning.

[LondonSquirrel]

1 minute ago, Old Bruce said:

Back in the bad old days it was simple in that copying a font meant a good chance of lead poisoning.

I had an Adana when I was 12. I felt like I was king of the world when I started printing things. An early mistake of mine which I still remember: setting the word 'services' as 'sevices'. It taught me a hard lesson after I had printed about 200 of these...