Convert fonts to outlines | option | PDF

[BBG3]

Having an outline option when we want to open a PDF file is very useful, especially when we don't have the fonts. Sometimes, people forget to outline their fonts before sending their files! It seems only Adobe Acrobat has an outline option.

Here is an example.

[GarryP]

8 hours ago, BBG3 said:

especially when we don't have the fonts.

Do you mean situations where the font (or subset) isn’t embedded in the PDF, or situations when the font isn’t installed on the machine you are opening the PDF on, or both, or something else?

[BBG3]

Hi @GarryP.

Both situations, but mostly those fonts are not installed.

1. It happens when we open some old files (like 10 years ago). We download some free fonts to do a project and then we uninstall them because we don't need them anymore and finding those fonts on the internet is very time-consuming.

2. Happens when we use Adobe fonts (Adobe Creative Cloud Fonts) in Illustrator or PDF files, which other applications can't access those fonts.

[Pšenda]

10 minutes ago, BBG3 said:

but mostly those fonts are not installed

But if the fonts are not installed, they were not inserted, and they were not converted to curves when exporting/creating the pdf file - so how does the application (which opens and displays the file) know what the given and unavailable fonts should look for convert them to identical looking ones outline?

[BBG3]

 

6 minutes ago, Pšenda said:

But if the fonts are not installed, they were not inserted, and they were not converted to curves when exporting/creating the pdf file - so how does the application (which opens and displays the file) know what the given and unavailable fonts should look for convert them to identical looking ones outline?

I don't know! I only know that Adobe Acrobat can convert any fonts you can see in a PDF file to outlines. 😊

[kenmcd]

3 hours ago, Pšenda said:

so how does the application (which opens and displays the file) know what the given and unavailable fonts should look for convert them to identical looking ones outline?

The shapes are there in the document - the fonts are not needed.
This is also how Ghostscript can convert any PDF to shapes (without the fonts).

You only need the fonts to edit the document.

This is how Adopey apps will display the text as-is - and only when you start to edit the text will the oddities start to appear. Such as when they display the mis-coded ligatures correctly (by just showing the shape that is there) and then display the errors as soon as you try to edit it. Then it goes from the display-shapes-that-are-there mode to the display-the-embedded-Unicode-codes mode and get the shapes for those codes from the font. Then the PDF ToUnicode table errors on the ligatures cause the wrong text to be displayed.

Think about it this way...
When you use OpenType to enter a swashy capital T, the Unicode code behind it in the PDF is still the capital T.
But the swashy T shape is there in the PDF.
The font is not needed.
And there is no OpenType code in the PDF telling it to show the swashy glyph.

The shapes and the codes behind them are separate things.

[Pšenda]

2 hours ago, kenmcd said:

The shapes are there in the document

That is what I wrote in the previous post - the outline/shape must be part of the document.

6 hours ago, Pšenda said:

converted to curves when exporting/creating the pdf file

 

[walt.farrell]

10 minutes ago, Pšenda said:

That is what I wrote in the previous post - the outline/shape must be part of the document.

I think @kenmcd is saying that the application generating the PDF doesn't need to do anything special. The shapes/outlines for the characters are always present in the PDF. 

It is up to the application opening the PDF to decide whether to use the characters or the shapes.

[GarryP]

11 hours ago, kenmcd said:

The shapes are there in the document - the fonts are not needed.

Interesting.

Are you saying (in a simple way that I can understand) that the shapes of the characters are ‘baked into’ the document no matter which export options are chosen but the software which displays the document may have a decision as to where to get the glyphs from when it displays it?

For example, (speaking from the document reader’s point of view):

• I get the document and it contains the outlines which tell me how to draw the characters;
• I may also get the font embedded in the document and so I have the choice to use that instead of the outlines;
• I may also be able to see the font installed on the machine so I also have the choice to use the installed font rather than the embedded font or the outlines in the document.

Or is it that the software reading the document only needs the outlines and it ignores any embedded/installed font which would only be needed if the software allowed for editing of the document?

Or have I not understood this at all? (That's very possible.)

[kenmcd]

16 hours ago, GarryP said:

Are you saying (in a simple way that I can understand) that the shapes of the characters are ‘baked into’ the document no matter which export options are chosen but the software which displays the document may have a decision as to where to get the glyphs from when it displays it?

If the font is embedded, yes.
The text object includes the shapes and the character IDs (CID).

Remember, PDF is really old, pre-Unicode, so text is identified by character ID.
Which, without getting caught-up in insane complexity, is basically a glyph number.
Old encodings had specific glyph numbers for specific characters - a CID.
That got expanded for big CJK character sets, even when fonts were only 256 characters (called character collections).
That got tweaked to support today's bigger fonts, etc.
Blah, blah, blah... PDFs still use CIDs.

PDF viewer applications simply show a shape displayed at specific coordinates.
The shape just happens to look like a letter T.
That text shape also has some text metadata connected to it.
A plain shape object (e.g. an ellipse) does not have this connected text metadata.

So converting the text to shapes means just dropping the text metadata.
Take the text shape out of the text object and just put it in a plain shape object.
And display that shape at the same coordinates.
It is now no longer "text" - it has been converted to "shapes."

Do not need the embedded font to be installed on the OS to do this.

OK, next bit of craziness... Display vs. Edit
PDF viewers just display whatever shapes are there - exactly what PDF was designed to do.
Editing is where it gets crazy - not what PDF was designed to do.

PDFs are supposed to have a ToUnicode table which maps the CIDs to Unicode code points.
Not all PDFs have a ToUnicode table, and some that do are wrong.
This affects the editing, copy-and-paste, search, screen readers, etc.
The applications that do these things are using Unicode code points for the characters.
Note: some older applications can use old encoding to do some of these things.
But modern applications are using Unicode.

We have seen some PDFs here in the forum which were created by some corporate report applications, or by some custom applications which have no ToUnicode table - and when opened in Affinity it is just a complete mess.

We have also seen multiple cases where the ligatures are not coded properly in the ToUnicode table - and they do not appear correctly.

What the reader or editor applications a capable of doing will affect what appears to happen.
Acrobat will not let you edit a PDF if you do not have the font installed (corp. decision).
Even if the whole font is embedded, and the font allows editing.
Some of my PDF editors will let me edit PDFs even with just a font sub-set embedded.
If a character is already embedded, I can use it. The shapes are there.
So what you can do depends on the application.

PDF viewers just show whatever text shapes are there (regardless of the mess behind them).

Affinity always opens the PDFs in edit mode (unless it is placed as pass-thru).
So it immediately wants to get the characters' Unicode codes from the PDF's ToUnicode table and then go get the installed font to render those Unicode characters for editing.
This is why Affinity needs the font to be installed on the OS.
The Affinity applications only work with Unicode.
So if the ToUnicode table is not correct or missing - errors appear.

Ironically Affinity does not encode the ligatures properly so if you open an Affinity-created PDF for editing there may be errors on the ligatures (note: have not checked this in quite awhile so it could be fixed...dunno).

Adopey ID will just display what is there (like a viewer) until you click into the text box to edit the text. So it is basically pass-thru until it is edited.
It would be nice if Affinity worked like this.

So, yes the text shapes are there if the font is embedded.
And the font does not need to be installed on the OS to convert text to shapes.

[GarryP]

Thanks for the explanation.

 I think it will take me some time to understand even a small part of what you’ve said, but it’s much appreciated.

[walt.farrell]

10 hours ago, kenmcd said:

Ironically Affinity does not encode the ligatures properly so if you open an Affinity-created PDF for editing there may be errors on the ligatures (note: have not checked this in quite awhile so it could be fixed...dunno).

From what I've seen here in the forums, the ToUnicode table for ligatures will be wrong (missing info?) if the PDF is created with font subsetting active, but correct (complete) if the user tells the Affinity application to embed the complete font.

[Petar Petrenko]

If you want to export an Affinity document into PDF, there is an option to convert text to outlines:
File > Export > PDF > Embed fonts > Text as curves.

[walt.farrell]

36 minutes ago, Petar Petrenko said:

If you want to export an Affinity document into PDF, there is an option to convert text to outlines:
File > Export > PDF > Embed fonts > Text as curves.

Useful info, but this topic is more about converting to curves on import.

[fde101]

Two things to consider:

• Some fonts are licensed in such a way that embedding them (or converting them to outlines to work around not being able to embed them) is not permitted.
• Converting a font to outlines disables hinting and may impact the quality of the produced image at low resolutions and small point sizes.

 

Neither of these points invalidate the proposed feature in general, but they do need to be considered whenever considering the implementation of a feature of this nature.

[thadeusz]

Hi,
thanks for pointing out the limits of Publisher working (or not working) with embedded fonts in PDFs. 
As this problem still exists, do you know any tool /app that could help out and could transform embedded fonts into paths - before importing the PDF into Publisher? And I'm not talking about Acrobat or Indesign.
Normally I don't need this functionality, but I'm about to start a project where I either find a solution or have to switch to Indesign or Acrobat to make sure that embedded fonts can be converted.

Many thanks for any ideas!
 

[wonderings]

On 11/15/2023 at 12:41 PM, BBG3 said:

 

I don't know! I only know that Adobe Acrobat can convert any fonts you can see in a PDF file to outlines. 😊

This is not completely accurate. Fonts need to be embedded into a PDF. If you do not embed the font in the PDF (this is done by default with Adobe software) it will preview correctly, but if you try and outline the fonts in Acrobat it will not work because the fonts are not present. 

 

On 11/17/2023 at 9:17 AM, fde101 said:

Two things to consider:

• Some fonts are licensed in such a way that embedding them (or converting them to outlines to work around not being able to embed them) is not permitted.
• Converting a font to outlines disables hinting and may impact the quality of the produced image at low resolutions and small point sizes.

 

Neither of these points invalidate the proposed feature in general, but they do need to be considered whenever considering the implementation of a feature of this nature.

Demo fonts cannot be embedded in a PDF, the work around is to outline them before saving the PDF. This of course restricts your editing and you may have to go back and forth saving a working file and an outlined file. Not ideal. 

I have not had image quality issues with outlined fonts, they are basically turned into vector artwork. 

[thadeusz]

Sorry, but that was not the question. As far as I know, If fonts are embedded in a PDF, Publisher can't handle them. I cannot simply import a PDF with embedded fonts into my Publisher layout and export it with the embedded fonts intact. So, there's the problem. Acrobat can convert those embedded fonts to paths. Indesign can preserve those embedded fonts on export - as one expects. Publisher can't do that.

The question was - is there a little tool/app, which can convert embedded fonts in a PDF to paths? That would help me to have a secure workflow with Publisher and embedded fonts in PDFs. Would be great if someone has an idea!

[Pšenda]

1 hour ago, thadeusz said:

Publisher can't do that.

And why doesn't he install these fonts?

[thadeusz]

Affinity Publisher can't do that

[Pšenda]

15 minutes ago, thadeusz said:

Affinity Publisher can't do that

I don't think you would install fonts by using APublisher, but install them using the standard OS path.

[thadeusz]

I was just correcting your quote. Who would think you could install fonts with Publisher? I dont get that. Please read my simple question again. 

[Pšenda]

1 hour ago, thadeusz said:

I was just correcting your quote. Who would think you could install fonts with Publisher?

I don't understand why you should correct my question, which was not related to APublisher at all, with information that you yourself subsequently consider meaningless. So I kind of get lost in your thoughts.

 

1 hour ago, thadeusz said:

Please read my simple question again. 

As for the question about "transform embedded fonts into paths", I ask again - why in a new project do you want to convert embedded fonts to curves, which are problematic to work with, and don't you just install the corresponding font, which of course is much better to work with?

[thadeusz]

5 minutes ago, Pšenda said:

why in a new project do you want to convert embedded fonts to curves, which are problematic to work with

Because you are working on a project, like a catalogue or a program for a film festival and you get PDFs from clients (advertisements et cetera) last minute. Of course you've told everybody beforehand that you would like your PDFs with curves instead of embedded fonts, because Affinity can't handle it... But, 50% of those people delivering their advertisements – or whatever they put into your layout – still with embedded fonts, as we all normally do, when we deliver for print. There you have it, this could easily turn into a bit of a nightmare. Without a solution I would definitely like to have access to Acrobat or start the whole project in Indesign. But I'm still hoping to find a good workaround...

[Pšenda]

4 minutes ago, thadeusz said:

But I'm still hoping to find a good workaround...

And in my opinion, the ideal solution is to get used fonts from the client, install them, and not worry about embedded fonts at all.

Otherwise, it is not a problem to export embedded fonts from PDF - there are several online tools for this.
https://www.pdfgear.com/pdf-editor-reader/extract-font-from-pdf.htm