Embed Font gets Outlined

[Xaphedo]

Hi!

When exporting my scribus file into a PDF one of the two fonts doesn't actually get Embedded, but Outlined.

In "Export" -> "Save as PDF" -> "Fonts" -> "Fonts to embed" I have both fonts, while "Fonts to outline" is completely empty. I'm not sure what's going on.

Once I export the PDF I can't select the text using the font in the reader, it's not listed in the embedded fonts in the file's properties, and it's definitely outlined (I checked via Inkscape). I can select the text which is using the other font though, which is embedded as it's supposed to be.

Any ideas? I've already looked around, and there doesn't seem to be any clear precedent to this

[attachment deleted by admin]

[GarryP]

Wecome to the forum Xaphedo.

I've just done a quick check - on WIndows 10 with Scribus 1.4.6 - on a document containing three text frames, formatted in:
* Roboto Medium - True Type - Embeddable;
* Dosis Medium - True Type - Embeddable;
* Open Sans Regular - True Type - Editable.

Exporting to PDF, the dialog I get after pressing the "Embed All" button is shown in CaptureExport.PNG
Both Roboto Medium and Dosis Medium are set to be outlined which seems odd because they should be embeddable.
(See here http://www.adobe.com/uk/products/type/font-licensing/font-embedding-permissions.html for more information.)

After export (Document-1.pdf) and reading in Acrobat Reader DC I get the properties seen in CaptureAcrobat1.PNG
One of the fonts - probably Dosis Medium - seems to have been converted to a Type 3 (Postscript) font, which doesn't sound right to me (see below).
The Roboto Medium text cannot be selected but the Dosis Medium and Open Sans Regular text can be selectable.

Going back to the document and the export dialog I pressed the Embed All button again, then selected Dosis Medium, pressed the "Up Arrow" (to move the font from Outlined to Embedded) and then selected Roboto Medium and pressed the "Up Arrow" to end up with the dialog as shown in CaptureExportMissing.PNG. One font to embed, no fonts to outline, which seems wrong to me.

[Forum restrictions mean that I have to split attachments on multiple posts from this point.]

After export (Document-1a.pdf) and reading in Acrobat Reader DC I get the properties seen in CaptureAcrobat2.PNG
Now I have the situation where Dosis Medium and Open Sans Regular seem to be embedded properly - but note that Open Sans is missing the Actual Font information - but there's still no Roboto.

Doing a similar thing as above but also removing Open Sans Regular from the list of embedded fonts - CaptureExportNoFonts.PNG - gives me Document-1c.pdf and CaptureAcrobat3.PNG. Something strange is happening here.

I have a feeling that Scribus isn't showing users the full story of what it's doing with fonts.
Because of this it's difficult to diagnose what's going on with the Roboto font. It's supposed to be embeddable but Scribus isn't embedding it for some reason and it's not telling the user why.

Maybe one of the font experts in the forum can help more.

[attachment deleted by admin]

[GarryP]

After having to wait more than 60 seconds to re-post (understandable but a tad annoying): Extra attachments...

[attachment deleted by admin]

[GarryP]

(Oh, when can we have better forum software? http://forums.scribus.net/index.php/topic,2328.0.html) These should be the last attachments for my previous post...

[attachment deleted by admin]

[jghali]

Hi,

Scribus 1.4.x generally outline fonts by generating PostScript Type 3 font subsets. To do so with TrueType fonts, a specific table is required: the 'post' table which contains the PostScript name of each glyph in the font. This table is optional and in the case of Roboto is missing. As a consequence we cannot generate a Type 3 subset for that font and have to take a more aggressive approach: convert the text using Roboto entirely to vectors. The font will be consequently not visible in Acrobat Document Properties.

Note that PDF specifications advise against TrueType fonts which lacks the Postscript glyph name tables in PDF files.

[GarryP]

jghali, could you clarify some points please:

1. You said that: "Scribus 1.4.x generally outline fonts by generating PostScript Type 3 font subsets" but Xaphedo was wondering why the font could not be embedded rather than outlined. Did you actually mean embedding rather than outlining? The font itself says that it can be embedded so what is stopping it from being embedded?

2. You said that: "This table [the 'post' table] is optional and in the case of Roboto is missing." From the TTF specifications I have looked at - from both Apple and Microsoft - the 'post' table is actually required. Does this mean that the Roboto font is "breaking the rules"? I know that 'required' may not exactly mean 'mandatory' but surely if it is okay for a font not have a specific table then it should be optional rather than required. Or is this just one of those things that happens even though it really shouldn't?

3. Scribus "knows" that a font cannot be embedded but there is no information given to the user, which is where the confusion - in this case - comes from. Is there a reason why Scribus does not give this information to the user? Telling the user why a font cannot be embedded would allow the user to make better font choices. For instance, say the user has created a large document with a lot of text that has been manually typeset. If, after many days/weeks of work, the user then finds out that the font cannot be embedded, and they will have to change the font, a lot of time will have been wasted. On the other hand, if the user is shown a little "warning, font cannot be embedded" icon next to the font name then they can choose a different font before doing a lot of work that will have to be scrapped.

4. Is there any way for a non-technical user to find out which of the fonts they have installed on their system cannot be embedded by Scribus? For example, could the Font Preview function be extended to show possible problems with the fonts? It currently has a checkbox for embedding but, for Roboto, it shows a check-mark when, since Roboto cannot be embedded, surely the checkbox should be blank and not checkable. It currently gives a false impression of what the situation is.

Basically, Scribus is already aware of various bits of information about the fonts that could be very important to the users. Would it not be better if that information was given to the users?

[jghali]

1. Same reason: missing PostScript glyph names. This prevent generating the PDF font encoding.

2. No, the Roboto font is not breaking the rules. The 'post' tag can be present but empty. As Adobe warns about it, such font will just be suboptimal for using on a PostScript device or on professional rips and can trigger compatibility problems when used on certain devices.

3. a) Scribus "knows" that a font cannot be embedded but there is no information given to the user, which is where the confusion - in this case - comes from. Is there a reason why Scribus does not give this information to the user?

This kind of information is very technical and almost no user would understand it. Even most layout pros wouldn't. In the case of Roboto, the font is already flagged as "subset" in font preferences. So there is already information given to user. But as I mentioned it already in several occasions (mostly on IRC), font preferences are expert stuff.

b) For instance, say the user has created a large document with a lot of text that has been manually typeset. If, after many days/weeks of work, the user then finds out that the font cannot be embedded, and they will have to change the font, a lot of time will have been wasted.

If user test the font he uses after doing his work, sorry but it's not up to us to fix bad and broken work habits.

c) On the other hand, if the user is shown a little "warning, font cannot be embedded" icon next to the font name then they can choose a different font before doing a lot of work that will have to be scrapped.

In font preferences, the font is already flagged with "subset".

4.  a) Is there any way for a non-technical user to find out which of the fonts they have installed on their system cannot be embedded by Scribus?

File > Preferences > Fonts. If a font is flagged with "subset", then that means Scribus has good reasons to not fully embed it.

b) For example, could the Font Preview function be extended to show possible problems with the fonts?

This is the job of font management softwares.

c) It currently has a checkbox for embedding but, for Roboto, it shows a check-mark when, since Roboto cannot be embedded, surely the checkbox should be blank and not checkable.

That checkbox relates to PostScript not PDF. The checkbox clearly says "Embed *in PostScript*". This checkbox has been removed in trunk anyway: with the new OTF related functionalities implemented in 1.5.3, we can hardly fully embed fonts in PostScript reliably.

The ability to embed a font depends not only on the font itself but also on the output format. Examples:
- PostScript Type 1 fonts can be embedded in PDF, not in XPS
- OTF fonts with Postscript outlines can be embedded in PDF 1.6, not in PDF 1.5 and below

The ability to embed a font does not depend only on the font itself, it depends also how you use it.

[GarryP]

Thanks for the quick response.

1. That makes sense. No PostScript table, no embedding in PDFs (or, at least, that's an easy way for me to remember it).

2. Ah. Seems like having the tag present but empty is pretty much the same thing as it being optional but if that's how it is then that's how it is. Just one of those things. Since Roboto was primarily designed by/for Google as a web font then it makes sense that the PostScript stuff was simply ignored.

3a&b&c. I think this is one of those "there's no right way" type of areas.

On the one hand, most users will just use their fonts and produce their documents and be happy without even knowing about what lurks underneath. On the other hand, real professionals will have good knowledge about the ins-and-outs of fonts and what they can and can't do in various ways. Unfortunately there's yet another hand, where the user is transitioning from being a novice and is starting to want to know more about how things work so they can do things better.

Scribus could just give everyone all the information they could possibly want and novice users would be swamped by (to them) meaningless junk. Or it could hide all of the information away and just present the user with the basics even though they might need to know some extra details later on. And there are all kinds of scenarios between the two (novice/expert modes, advanced tabs, etc.).

A difficult area to get a good balance. Maybe it's right that Scribus forces people to learn more about what they're doing so they do it right. Learn how to use your tools properly or keep hitting yourself on the thumb with your hammer. I don't think there's a correct answer here, I just think that Scribus could give a little bit more information about what's going on but I don't know where to draw the line.

For instance, in this scenario, is it right that the user should have to find out about 'post' tables in TTFs and that they are sometimes empty which would lead Scribus to not be able to embed the font? Or would it be better if Scribus gave a little message like "You can't embed that font because it does not contain PostScript information" when someone tries to embed it. I'd probably lean towards the latter but that's just me. The user might be none the wiser about how to change things but at least they know what's wrong.

4a. I'll have to try and remember that. Not easy to join the two concepts - especially as I can manually un-check the checkbox (whatever that does)  - but if it's all we have then it's what we've got.

4b. That's fair enough I suppose. I've seen some software that dumps a font so you can see what's going on but they're all command line things. If anyone reading this can recommend something similar that's free and uses a GUI on Windows then please shout up.

4c. Ah. If it's being removed then there's no point wondering about it. Goodbye "Embed in PostScript", you will be missed (possibly).

This font stuff is way too complicated for my simple needs but it's interesting all the same.

Anyway, thanks for explaining things a bit more. Hopefully it's given a lot of people pause for thought about how they use fonts and also given them a bit of a nudge into reading up about them more (it certainly has for me).