Jump to content
You must now use your email address to sign in [click for more info] ×

How does Publisher handle non-embeddable fonts?


Recommended Posts

In other DTP applications I've used, sometimes there are fonts that cannot be embedded for whatever reason. The usual reason is because they have copyright/license restrictions, but there are others that don't come to mind at the moment. The other DTP software outlines - converts to vectors - these fonts. I was wondering what Publisher did with fonts like these. Does it outline the text or do something else?

I've had a look around the Help, various dialogs, and this forum and can't find anything related to embedding/outlining fonts.

Also, on a related note, is there a way to force Publisher to outline either everything in a particular font, or a specific piece of text, or the contents of a specific text frame? I ask this question as I sometimes want to have certain text outlined so that non-human readers can't read the text - e.g. phone numbers, email addresses, etc. In other software I've used a specific font for these items and then told the software to outline everything that uses these fonts. I could manually convert certain items to curves but that's a bit awkward, especially for editing purposes.  (Also, sometimes I find that a certain browser/PDF-reader has trouble with a certain fonts when they are embedded so I use outlining for this reason too.)

Link to comment
Share on other sites

You can’t embed fonts into any layout software. Are you perhaps thinking of embedding fonts into the PDF output?

If yes: Do you own an unembedable font? If yes, just try it and report back. I have no such fonts, because I’d never buy it. It is one thing, hand over fonts, and another thing to embed them.

(Normally, PDF doesn’t even allow to edit an embedded font, it it isn’t installed on your machine.)

Link to comment
Share on other sites

2 hours ago, GarryP said:

is there a way to force Publisher to outline either everything in a particular font, or a specific piece of text, or the contents of a specific text frame?

Just normally, select text object, Layer > Convert to Curves

Link to comment
Share on other sites

1 hour ago, mac_heibu said:

(Normally, PDF doesn’t even allow to edit an embedded font, it it isn’t installed on your machine.)

That shouldn't apply to a font whose embeddability flag is set to either 'Installable' or 'Editable'.

Alfred spacer.png
Affinity Designer/Photo/Publisher 2 for Windows • Windows 10 Home/Pro
Affinity Designer/Photo/Publisher 2 for iPad • iPadOS 17.4.1 (iPad 7th gen)

Link to comment
Share on other sites

I seem to have inadvertently created some confusion so I'll try and re-word my questions.

1. If I have a document which has text that is formatted with a font that is not embeddable - for whatever reason - what happens when I export that document as a PDF? Does Publisher convert the text to vectors, or does it omit the text, or something else?

2. Is there a way to tell Publisher, at the point of exporting to a PDF, to automatically convert some user-specified text to vectors - just for the function of exporting, leaving the text in the document as it was - without manually converting it within the document myself?

It is my - very limited - understanding that some fonts, even if they are marked in the font file as "Embeddable" or "Installable" may not always actually be embeddable because they have no Postscript information. I'm fairly sure that Roboto may be one of these fonts because it is missing a "post table" (whatever one of those is) but this sort of thing is way beyond my level of expertise.

I think I already have the start of an answer to my first question. On a WIndows 10 machine I created a document (attached) with three text frames of filler text. One formatted in "Segoe UI", one in "Segoe Print", and one in "Segoe MDL2 Assets" (all Microsoft fonts). I exported - with Build 58 - the document as PDF and copied the resultant file to an old Linux Mint laptop. Opening the PDF (also attached) in Atril Document Viewer the fonts are listed as "SegoeUI", "SegoePrint" and "ArialMT". The same is true when opening the PDF in Adobe Reader on the same Windows machine it was created on. "Segoe MDL2 Assets" is marked as "Editable" under Font Embeddability in WIndows 10. It seems as though Publisher is automatically converting some of the text to Arial, but this isn't an exhaustive test by any means.

I would say that this issue needs an export looking at it rather than me just stabbing at things in the dark.

font-test2.afpub

font-test2.pdf

Link to comment
Share on other sites

My attempts to import PDF files have shown that Publisher can not read the fonts embedded in the kind of files. When I import PDF file (see the picture 1) into Publisher I get this (see the picture 2). Every font is changed into Arial. According to FontLab all the four fonts embedded in the example PDF file have attribute "Everything is allowed."

This means that when I receive a PDF file from a client, he/she will have to attach to it the fonts used in this file or to convert them into curves... or to convert the PDF file into a bitmap. In InDesign, I do not have to do this because InDesign handles the PDF files correctly, including the embedded fonts.
 
Is it a bug or am I doing something wrong?

PDF Font Test 1.jpg

PDF Font Test 2.jpg

Link to comment
Share on other sites

Hi Fierys,

Dave Harris already provided an answer to your question:

https://forum.affinity.serif.com/index.php?/topic/54165-pdf-import/&page=2&tab=comments#comment-276394

The applications of the Affinity Range will decompile any PDF document to primitives in order to be able to draw it. So in order to display your PDF document correctly, you will have to install the fonts, regardless of the font settings. But make sure to have a look at the discussion subsequent to the linked post, for MikeW added a suggestion for dealing with the issue you described.

Alex :)

Link to comment
Share on other sites

Is there a way to tell Publisher, at the point of exporting to a PDF, to automatically convert some user-specified text to vectors - just for the function of exporting, leaving the text in the document as it was - without manually converting it within the document myself?

No, currently this is an all-or-nothing setting. You can either convert all of your text to curves or none of it during export. There is no way to mark particular sections of your text for being converted to curves on export. :(

Unfortunately, I don’t have any font that would be not embeddable … and I won’t license such fonts … so I fear I cannot give you any advice. Roboto is embeddable, from a technical as well as from a legal point of view. Do you, by any chance, have an Open Source font that is non-embeddable, such that we can test this?

Link to comment
Share on other sites

@A_B_C That's a shame. It would have been nice to be able to specify which text was converted to vectors - without doing it manually - but it's not a 'show-stopper' for me.

I definitely think the fact that Publisher doesn't warn you of font substitution on PDF export is a big issue though. That may be a 'show-stopper' for a lot of people, especially professional DTP people.

I think the Roboto line of thinking may be a red herring. I remember having issues with it on my old Mac a good while ago in some other software and the problem was to do with embeddability/Postscript (because it was primarily a web font) but this might not be relevant to Publisher.
 
As for testing, I'm not sure any Open Source fonts will be unembeddable; I've certainly not seen one. If the font itself is Open Source and, as such, anyone can modify it as they wish - within the limits of the license - there would be not much point in anyone setting it as unembeddable. All someone else would have to do is make their version embeddable and the original becomes a less-useful, and therefore less-popular, font. As a big point of Open Source is sharing, it doesn't seem to make much sense to make it un-shareable. I could be wrong in some instances though.

I think any testing would need to be done with one of the Apple/Microsoft fonts that come with the individual OSes. They are the ones that are more likely to have strict licences and are ones that people are most likely to be using.

P.S. It might interest some people to know that PDF submissions to the US Patent Office must have fonts embedded (except those fonts on their standard list) : https://www.uspto.gov/custom-page/pdf-requirements It's probably not relevant here, just interesting; well I think so anyway.

Link to comment
Share on other sites

On 9/8/2018 at 8:50 AM, GarryP said:

It is my - very limited - understanding that some fonts, even if they are marked in the font file as "Embeddable" or "Installable" may not always actually be embeddable because they have no Postscript information. I'm fairly sure that Roboto may be one of these fonts because it is missing a "post table" (whatever one of those is) but this sort of thing is way beyond my level of expertise.

I don’t think the presence or absence of a PostScript Table should affect the embeddability of a font. The ‘post’ feature seems to be specifically related to the ability to use TTF or OTF fonts on PostScript printers.

https://docs.microsoft.com/en-us/typography/opentype/spec/post

Alfred spacer.png
Affinity Designer/Photo/Publisher 2 for Windows • Windows 10 Home/Pro
Affinity Designer/Photo/Publisher 2 for iPad • iPadOS 17.4.1 (iPad 7th gen)

Link to comment
Share on other sites

As for testing, I'm not sure any Open Source fonts will be unembeddable; I've certainly not seen one. If the font itself is Open Source and, as such, anyone can modify it as they wish - within the limits of the license - there would be not much point in anyone setting it as unembeddable.

That’s very true, Garry! :D

So here is my understanding of the matter. In TrueType or OpenType fonts, the embedding licensing rights are stored in the entry fsType of the OS/2 table. By setting the respective value, you can specify, among others, that your font 

  • can never be embedded into documents,
  • can be embedded into documents that can be printed but not edited,
  • can be embedded into documents that can be edited,
  • or can be embedded into an editable document and later extracted and installed on a different system.

These are just some of the available options. When you have a look at the fsType setting of Source Sans Pro, you can see that fsType has the value 0x000 (no bit is set) which is the most liberal setting (“installable embedding”). Fonts with this setting can be embedded and permanently installed on the remote system by an application.

Other fonts might come with less liberal settings, and of course, you can take a font and change the fsType settings, such that embedding of this font is prohibited. I tried with a font whose license allowed me to do so, and while Indesign gave me a warning and didn’t embed the font, Affinity Publisher seemed to simply ignore the fsType setting and embedded the font into my PDF. At least, this is my understanding and what I can report. As this touches legal issues, my remarks should not be construed as legal advice.

Alex :)

 

Source-Sans-Pro.thumb.png.f59850b0dd54f07759f8cd00aa37b70c.png

Warning.png.7dfbe2b16a4652d6ec1d5d4dd02d31e1.png

Link to comment
Share on other sites

10 minutes ago, A_B_C said:

These are just some of the available options.

What other options are there, Alex? :/ There are only four flags, and if multiple flags are set then the least restrictive one takes precedence.

Alfred spacer.png
Affinity Designer/Photo/Publisher 2 for Windows • Windows 10 Home/Pro
Affinity Designer/Photo/Publisher 2 for iPad • iPadOS 17.4.1 (iPad 7th gen)

Link to comment
Share on other sites

I believe you are referring to this article, Alfred:

https://docs.microsoft.com/en-us/typography/opentype/spec/os2#fstype

But you must imagine that the first four options can be combined with the “subsetting” rule (bit mask 0x0100) and the “bitmap embedding only” rule (bit mask 0x0200), so there are, from a combinatorial point of view, quite a few more options.

––––––––

Suppose, for instance, that I use the following rule set for my font:

Fontlab-A.png.b08db13969dec93ab6c44e5145a39907.png

Then fsType will have the following value:

fsType-A.thumb.png.e2788a6c4f5ba18635d0d3293bfeb82b.png

––––––––

However, when I use the following rule set:

Fontlab-B.png.35c9e65382989809cfacb021341e1693.png

Then fsType will have this value:

fsType-B.thumb.png.a8e42ca2362087a36399f80706c6fe96.png

––––––––

So you can see, these other options have to be taken into account too, though I am not sure about their practical value. For why would you allow subsetting a font and at the same time forbid embedding the font altogether? :)

Link to comment
Share on other sites

I must confess this entire “embedding rights” topic is a bit obscure to me, and I didn’t really dive very deep into the matter. As I said, I wouldn’t purchase a license for a font or use a font that cannot be embedded, and the license agreements are usually very clear about this. (Yes, I do read license agreements.) Non-embeddable fonts are just too cumbersome to handle. Maybe MikeW could enlighten us a little more about all this. I think he is pretty versed in these legal and technical issues. :)

Link to comment
Share on other sites

This is turning into a very interesting discussion. I don't understand it all, but it's interesting nonetheless.

Alfred: I think the Postscript thing could well have been something specific to the other software. I only brought it up in case it happened to be important (as I don't know much about this area).

While I feel sure that most DTP/illustration/design professionals will know their fonts inside and out, I'm also sure that most 'normal' people using Publisher will be unaware that there could be issues with font embeddability (or even that 'embeddability' is a thing they need to know about). Even if someone knows their fonts well, they may be required to use a specific font - a font they're not used to using - by their client so I think it would be very useful to all types of user if Publisher could warn of any issues way in advance of a PDF being created. No-one wants to put in weeks of work getting everything just right and then finding out that one or more fonts have been substituted and large amounts of the layout will need to be changed at short notice.

At the same time, while I'm sure that most professional DTP/illustration/design users will meticulously check every PDF before it goes off for printing, most 'normal' people will probably assume that what they see on the screen is what they will get in the PDF and, therefore, on the printed page, and might only do a cursory check, if they check it at all.

I don't know the best way to get round this problem as I don't know how Publisher works 'under the hood' but, as stated near the start of this thread, a simple status icon that the user can keep an eye on linked to a clickable list of warnings/errors may be a reasonable way to go at first. At least that would give users a 'heads up' that something is a potential problem rather than relying on them checking for things they might not necessarily know about in the first place.

Another option might be to add a new group of settings to the New Document dialog where the user can state which types of fonts are allowed to be used. However, while this should stop the 'embeddability issue' occurring in the first place, it might be confusing for some/most users and might cause further issues, for example when importing documents.

Or there could be an "Embeddable" tab in the font drop-down lists. (There are probably way too many ways of doing this and everyone will have their favourite so not everyone will be happy with the end result, whatever that may be.)

All said, I really think something needs to be done about this but I don't know what would be best. I'm sure the developers will have some great ideas and I trust that whatever they come up with will be in-keeping with the professionalism of the Affinity range we have come to know.

P.S. Designer also needs this function, not just Publisher. (Just thought I'd say.)

Link to comment
Share on other sites

15 hours ago, A_B_C said:

you must imagine that the first four options can be combined with the “subsetting” rule

As you probably guessed, Alex, I forgot all about subsetting! :o

Anyway, I agree with @GarryP that we need automatic ‘preflight’ warnings about these kinds of issues to avoid nasty surprises for users who might not think of checking for them.

Alfred spacer.png
Affinity Designer/Photo/Publisher 2 for Windows • Windows 10 Home/Pro
Affinity Designer/Photo/Publisher 2 for iPad • iPadOS 17.4.1 (iPad 7th gen)

Link to comment
Share on other sites

Absolutely. :)

  • Provided that my findings are correct, I would want to suggest that the Affinity apps should respect embeddability flags. The will of a font developer concerning their own creations should always be acknowledged and respected.
  • And secondly, embeddability problems as well as other preflight issues should be reported to the user.

I don’t believe though that a new group of settings to the New Document dialog where the user can state which types of fonts are allowed to be used would make sense. For you will not always have to embed fonts. Sometimes you just print directly from Publisher or output your files to a pixel-based format or just convert your type to curves on export. All that does not count as embedding. But I understand the desire that users might want to learn a bit earlier about embeddability issues. It is terribly frustrating to spend days and days of perfecting a design, only to learn eventually that you cannot realize it in the desired way because of license restrictions.

Link to comment
Share on other sites

@A_B_C Yeah, my idea of extra options on the New Document dialog wasn't great. All of your reasons are good ones for not thinking down that route. I've since thought of some others too. Totally agree.

@Fixx I think that - as you say - just having a warning at time of exporting would be okay at first; it would be better than nothing. I also agree that a proper preflight feature would be an important add-on in Publisher's near future.

While it would be nice to have various extra features in Publisher I would personally prefer to see the developers come up with a rock-solid 1.7 which does everything it currently does, albeit with the bugs fixed, even if some much-needed features were omitted. Then, once it's been properly released, they can start to add new features in a timely manner. E.g. 1.7.1 - Add Preflight feature, 1.7.2 - Add data merge feature, etc. Otherwise there's a chance that the software could be in beta for way too long. While it stays in beta there's a chance that the next release won't read some documents made with the previous version and - in my opinion - that's a worse position than not having extra features.

So, even though I've been saying that a proper preflight feature is pretty vital, I'd still prefer that its introduction was postponed while the existing code is being hardened for a proper release. As an analogy, I'd prefer to drive a basic car that I know I can trust rather than a fancy one that breaks down all the time.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.