PDF music files in Publisher

[ms.fuentecilla]

Please can someone tell me how to get pdf music files into publisher without it converting everything to gibberish? I need to make enlarged prints! Photo does the same when I import pdf instead of opening them as image files.

Such efficiency at 'conversion' is laudable but not required in this instance!

[emmrecs01]

@ms.fuentecilla

What is the source of those files (what program was used to create them) and how, exactly, are you opening them in APub?

I have pdf music files exported from Sibelius which, if I simply use File>Open in APub, everything seems to be enclosed in annoying text boxes; if I use File>Place everything seems to be imported without problem.  You describe what you see as "gibberish".  Do you mean notation (and text, if used) are both completely scrambled and unreadable?

What do you mean by "enlarged prints"?  Is it that you want, e.g., one current "page" to be spread over two pages?  If so, I think that might be "more difficult"!!

Jeff

[walt.farrell]

Typically you would (at a minimum) need to have the fonts installed on your system if you're going to Open those PDF files in an Affinity application, @ms.fuentecilla.

But you should be able to use File > Place to put them into an Affinity document, and use Passthrough mode (setting on the Context Toolbar) to avoid the need to have the fonts. This should avoid any gibberish.

[ms.fuentecilla]

EMRECS: I just want to enlarge parts supplied in a pdf folder for rehearsal so that I can read them more easily, in short to print them larger on each page. So I just need the original opened as an image in any Affinity programme. Quite simple. If I try file place, Walt, only one page (the title) is placed not all pages contained in the pdf file, which I might have expected. Pass through mode seems not available as part of any menu I can find. 

Editing pdf in Affinity is new to me, so I am really searching!

What I mean by gibberish is one symbol repeated on the staves without any resemblance to musical notation, suggesting your comment about the need for fonts perhaps.

I don't know what software was used to make the pdf's.

The only way I have been able to do anything so far is by printing from Acrobat in the original pdf and reducing the printer's margin setting. Bit frustrating. It perhaps reveals a limitation in Affinity handling of pdf format and a limitation in my knowledge of pdf.

Thank you for your replies. I shall keep trying because I have to learn this music for a performance!

Happy New Year

Michael

Wienerwald.complete.pdf

[David in Яuislip]

Try this:
New document, I used A3 portrait
File/Place Wienerwald.complete.pdf
Resize
Set Spread to Page2
Right click and select Duplicate
Select new page from page panel on the left
Click on score in main panel
Set Spread to Page3
etc

[walt.farrell]

7 hours ago, ms.fuentecilla said:

only one page (the title) is placed not all pages contained in the pdf file, which I might have expected. Pass through mode seems not available as part of any menu I can find. 

You have to Place it individually for each page of the PDF, or use a duplication trick like @David in Яuislip showed above. Passthrough is a setting in the Context Toolbar (also visible in his post),

[Fixx]

If you just need sheets bigger you might:

- print to A3 paper at 141 % (or bigger, essentially cropping extra)

-crop all pages leaving only notes (Acrobat Pro and Apple Preview can do this at one go)

- or you can place each page/duplicate imports and set page view in Publisher; and then do scale/crop as needed.

[ms.fuentecilla]

Walt: Affinity does not permit me to select individual pages from the original PDF when using Place. I now know the PDF's were produced with Acrobat as image files. I shall try David's suggestion when I am more awake tomorrow.

EMRECS: see attachment

[walt.farrell]

1 hour ago, ms.fuentecilla said:

Affinity does not permit me to select individual pages from the original PDF when using Place

Yes, it does. You seen to have turned off the Context Toolbar, which is critical for using the program, and would show you that option.

View > Show Context Toolbar

[thomaso]

On 12/29/2021 at 1:12 PM, walt.farrell said:

Typically you would (at a minimum) need to have the fonts installed on your system if you're going to Open those PDF files in an Affinity application

Any idea what it depends on which glyphs get used when opening this PDF with the font installed? It seems the correct glyphs are available but APub has diffculties to interprete them correctly. Note here in the selected layer showing '?' for the glyphs I replaced via the Glyph browser (from initially 'oe' ligature).

[kenmcd]

2 hours ago, thomaso said:

Any idea what it depends on which glyphs get used when opening this PDF with the font installed? It seems the correct glyphs are available but APub has diffculties to interprete them correctly. Note here in the selected layer showing '?' for the glyphs I replaced via the Glyph browser (from initially 'oe' ligature).

The font used on the music is Petrucci - which is a Symbol font, not a Unicode font.
This used to be the default font in Finale (the PDF info shows it was created in Finale 2007).
Most of the music "text" shows MacRomanEncoding as the embedded font encoding.
In normal MacRomanEncoding the œ character has a GID (glyph ID) of 138.
In this font the most used black note (oval) glyph has GID 138.
So it appears that APub is displaying the MacRomanEncoding GID 138 œ glyph from some other font rather than the GID 138 glyph from the font.
There is a cmap table in the font which does map this to the GID.
So it should be possible to read the font data and match this up.

This encoding is how someone would use keyboard codes to enter these characters.
They had a character map for their keyboard (most of us have used something similar).

It appears from this and some other examples we have seen that APub/Affinity treats all imported characters as Unicode, and looks at the GID and then looks to find the Unicode match for that. ???  I do not know.
It should be possible to connect the dots. But that would require matching the fonts, then reading the installed font data (to get the cmap info), and then using that font to edit.
But does APub only support Unicode fonts?  If yes, then this is not going to happen.

So my final guess is - APub sees MacRomanEncoding, and knows that in that encoding the GID 138 is the œ character, and that in Unicode the œ character is code point 0153, so it applies that Unicode code point and displays that Unicode code point, which does not exist in the original symbol font, so it displays a fallback font for that code point.

[lacerto]

On 1/5/2022 at 4:21 AM, LibreTraining said:

So my final guess is - APub sees MacRomanEncoding, and knows that in that encoding the GID 138 is the œ character, and that in Unicode the œ character is code point 0153, so it applies that Unicode code point and displays that Unicode code point, which does not exist in the original symbol font, so it displays a fallback font for that code point.

I wonder what actually determines how an app uses an embedded font: whether it tries to use it mapped to an installed font and to render text as text, or converting embedded text to curves, keeping the outlook.

E.g., OP's file is correctly rendered by Adobe Illustrator, but mostall glyphs using Petrucci are converted to curves, even if the font is installed. On the other hand, apps like Xara Designer Pro can open the file and directly use the embedded font (though in limited scope), rendering the musical notation correctly, but do not allow or support mapping of the embedded fonts to installed fonts (that would make everything fully editable). CorelDRAW (2017), VectorStyler and QuarkXPress (2018), similarly as Affinity apps, each render the font incorrectly when the file is opened for editing.

The preferred behavior would be giving the user the following options:

a) Mapping embedded glyphs to glyphs of the installed version of the font (perhaps not possible if the font uses custom encoding, which might be a result of embedding a sub set at export time?).

b) Converting embedded glyphs to curves, allowing perfect rendering (whether the actual font is installed or not; supported by Illustrator).

c) Using embedded glyphs (whether the actual font is installed or not; supported by e.g. Xara Designer or PDF X-Change; I am not sure if this is limited by embedding rights, but using existing glyphs is certainly technically possible, but only a few apps seem to support this).

d) Passing through (supported e.g. by InDesign and Publisher).

e) Rasterizing text but keeping other elements editable / in vector format (do not know an app supporting this).

f) Rasterizing everything (supported e.g. by Photoshop and Affinity apps, when rasterizing PDF placed for pass through).

One possibility is to use macOS Preview, Ghostscript (including PDF Output Preview which uses Ghostscript for font flattening of entire PDF files) or Adobe Acrobat Pro to flatten the fonts (convert text to curves), which would keep everything else unchanged, and then open the resulting PDF in e.g. Affinity Publisher for editing. 

[ms.fuentecilla]

These are very interesting replies, in that I tried also using Libre Office pdf. And thank you very much for identifying the software used to create the original pdf's. Although very experienced in using windows computers (from 1987) I am also a bit long in the tooth. Presumably then these pdf's were created in Mac, but that should make no difference, should it.

Until Affinity are back at work there is little that can be achieved, or so I feel, because from these last valuable responses it would seem a limitation in software compatibility and I also have another issue with Publisher on hold.

Walt: Context toolbar is set permanently on as it is necessary for all my uses of Publisher. The total pdf appears but it is impossible to select pages and place them. Selection produces only the title page no matter where I click. 

David: I tried this but it doesn't seem to differ from trying to place individual pages.

[walt.farrell]

2 hours ago, Lagarto said:

Converting embedded glyphs to curves, allowing perfect rendering (whether the actual font is installed or not; supported by Illustrator).

I think that option first requires that the application support embedded fonts, or that the computer has the correct font installed. Otherwise how would the application know the font characteristics that would be required to generate the curves?

[walt.farrell]

1 hour ago, ms.fuentecilla said:

Walt: Context toolbar is set permanently on as it is necessary for all my uses of Publisher

It's not permanently on, or it would be in your screenshot. Please turn it on, and use Place again, and you'll see that you can choose a page. And if you can't, please provide a new screenshot with the Placed file and the Context Toolbar.

[thomaso]

9 hours ago, LibreTraining said:

It appears from this and some other examples we have seen that APub/Affinity treats all imported characters as Unicode, and looks at the GID and then looks to find the Unicode match for that. ???  I do not know.
It should be possible to connect the dots. But that would require matching the fonts, then reading the installed font data (to get the cmap info), and then using that font to edit.
But does APub only support Unicode fonts?  If yes, then this is not going to happen.

Doesn't Affinity behave ambiguos here because its Glyph Browser is obviously aware about the available glyphs? This makes me assume (~ expect) that Affinity actually would be able to interprete + map the glyphs correctly when opening such file. Though the Glyph Browser does not generally show (recognize ?) all glyphs of each font (for some text fonts the browser remains empty though the text appears correct) – here with the Petrucci font the Glyph Browser knows about the 'missing' which get called by the Font Manager "unsupported glyphs" although they can be used. – So what part exactly doesn't work properly, @Serif?

On 12/29/2021 at 1:12 PM, walt.farrell said:

Typically you would (at a minimum) need to have the fonts installed

Walt, did you have any specific aspect or property in mind which made you say "at a minimum"? What further aspect could avoid the issue here, what properties would fulfil "a maximum"?

[walt.farrell]

19 minutes ago, thomaso said:

Walt, did you have any specific aspect or property in mind which made you say "at a minimum"? What further aspect could avoid the issue here, what properties would fulfil "a maximum"?

Having the font installed is the minimum.

Beyond that, there have been other discussions that even with the music fonts installed, editing the PDF in an Affinity application doesn't work, so there is something more that is needed but I have no idea what. This discussion has gotten deeper into the details than others that I recall reading.

[David in Яuislip]

2 hours ago, ms.fuentecilla said:

David: I tried this but it doesn't seem to differ from trying to place individual pages.

Without seeing screenshots I can't comment, however if you follow my first post, you will create new pages in a Publisher document which contain a reference to the entire Wienerwald.complete.pdf document, you then choose which page to display using Spread: Page N in the Context Toolbar

Try the attached as a starter

Wienerwald3pages.afpub

[lacerto]

2 hours ago, walt.farrell said:

I think that option first requires that the application support embedded fonts, or that the computer has the correct font installed. Otherwise how would the application know the font characteristics that would be required to generate the curves?

I am not sure what this exactly means. In what sense do Affinity apps not support embedded fonts? They can use them to rasterize text that uses an embedded font not installed on the computer, when the font is embedded in a PDF, and they can use them to convert to curves text that uses an embedded font not installed on the computer, when the font is embedded in an EPS file. But they cannot pass through an embedded font within an EPS file, nor can they convert to curves an embedded font within a PDF file (both of which Adobe apps can do).

The PostScript file below (first score page of the OP's file) is an EPS file that contains subset fonts. If you open it in Affinity Designer, it renders the musical notation as curves whether you have Petrucci installed or not. If you open the file in Adobe Distiller, it can create a PDF file with embedded fonts from the file and score notation rendered with fonts, whether you have the referred fonts installed or not.

Wienerwald.page1.ps

So I think that my question is valid: what exactly determines what happens when a file with embedded fonts is opened? Obviously an installed font is required to be able to map embedded glyphs to fully editable characters, but this does not seem to happen when symbol fonts (and custom encoded sub sets of regular fonts) are used. But when using embedded fonts, what actually happens seems to be partially related to embedding permissions (and whether the editing app honors them), when such text is opened as editable text, but possibly also to technical capabilities of the app, which might be related to licensing of supporting code (but if so, it is odd that Ghostscript can convert to curves embedded uninstalled fonts within a PDF file). 

EDIT: I do not know PostScript well enough to be able to say whether the attached PS file includes both font-rendered and already pure outline versions of the included page, but if it does, then it is likely that Affinity apps directly just use the version already converted to curves. But then how can they pass embedded fonts when they are within a PDF file (but not when they are part of EPS files), and how can they rasterize text within a PDF typeset in embedded fonts not installed on the system?

[walt.farrell]

2 hours ago, Lagarto said:

I am not sure what this exactly means. In what sense do Affinity apps not support embedded fonts?

In the sense that you cannot Open a PDF that contains text using a font that you do not have installed, even if the font is embedded in the PDF file, and get fidelity. Nor can you Place it if using Interpreted mode.

[lacerto]

On 1/5/2022 at 5:45 PM, walt.farrell said:

In the sense that you cannot Open a PDF that contains text using a font that you do not have installed, even if the font is embedded in the PDF file, and get fidelity. Nor can you Place it if using Interpreted mode.

I think that Adobe Illustrator fully supports embedded fonts, but you cannot open OP's file there for editing (while retaining text as font), either, even if you have the font installed. I think it is related to embedded font having been encoded in a way that cannot directly be mapped to installed fonts, and that Illustrator (at least CS6) does not even offer options to map the font. Whether this is dependent on custom encoding of a subset font, or that of a symbol font, I have no idea.

But the point of embedding is providing support of using fonts without needing to have a purchased license just for production (and normally prohibiting their use for editing or creation), and without needing to have these fonts installed on the production system.

Affinity apps do support embedded fonts in the sense that in PDFs they can be passed through, and rasterized if wished, and in EPS files they can be converted to curves. The difference to Adobe apps is that Adobe apps can pass through embedded fonts also in EPS files, and convert to curves fonts embedded in PDF files not installed or not mappable to installed fonts. The latter feature, as mentioned, is also provided by e.g. macOS Preview and Ghostscript, but I would not count these as features that determine whether an app can be said to support embedded fonts in PDF files or not. Being able to convert embedded fonts to curves is a very useful extra feature, though.

EDIT: Having further examined the behavior of Illustrator when opening OP's file after having uninstalled the font (Petrucci), it appears that AI converts to curves most of the notes and musical symbols ("To preserve appearance, some text has been outlined.") -- even when the font is installed. At the same time, part of the glyphs are correctly mapped to Petrucci glyphs when it is installed, and replaced with another font when it is not installed. The replaced glyphs could easily be later located by using the Find Font feature and replaced with the desired font. But the result would be less than satisfactory if a replacement font needs to be used. Accordingly it appears that even Illustrator (CS6) could not open this specific file for editing and fully keep the appearance, in case the font Petrucci would be missing. As it is, if editing is needed, the fonts should first be flattened e.g. by using the flattening or prepress tools of Adobe Acrobat Pro, or using Ghostscript, or alternatively, exported to PS or EPS format (e.g. using macOS Preview or Adobe Acrobat Pro).

[thomaso]

16 hours ago, LibreTraining said:

Most of the music "text" shows MacRomanEncoding as the embedded font encoding.

6 hours ago, walt.farrell said:

even with the music fonts installed, editing the PDF in an Affinity application doesn't work, so there is something more that is needed but I have no idea what.

If I create in APub a text frame with some glyphes of font Petrucci and export that from Affinity I would expect to get it opened correctly if opened in APub. (no matter wheather font export as subset or not). So it seems Affinity does not fully read its exported content of a reopened PDF. – While the OP's PDF shows "MacRomanEncoding" my test PDF shows "Identity-H" as encoding.

From another forum I found the following post which makes me wonder if Affinity can be able in general to open its PDF correctly or if Affinity is currently "just" lacking the mentioned mapping table or entry "/ToUnicode". – Wouldn't Affinity need this to export this .afpub as PDF / or is this part of the PDF-lib used by Affinity?

Quote

 

Also, Identity-H is just a 1:1 character mapping for all characters from 0x0000 to 0xFFFF. ie. Identity is an identity mapping.

Your real problem is the missing /ToUnicode entry in this PDF. I suspect there is also an embedded CMap in your PDF that explains why there could be 3 bytes per character.

 

 

Aside the glyph mapping: what influences the tracking presented by APub when it opens its PDF? I guess a glyph mapping never would include tracking (but kerning only from the font file) and in particular not such extreme values like -300 instead of +150.

Even copying the PDF content from the PDF + pasting it into APub doesn't show such strange tracking but keeps the initial 150. – So what is causing such wide range of various values if the PDF gets opened by APub?

[kenmcd]

First, editing music using this symbol font in a text editor ... is simply never going to work.
Even if when the PDF is opened the "correct" encoding is applied.
Most of the layout was done by by Finale 2007.
The vertical placement of the notes (symbols) is done by Finale.
And some of the horizontal placement is also done by Finale.
What you would think of as normal font metrics does not exist.
Finale is a very specialized application which places symbols on a page to look like music.

Some of the newer music fonts are Unicode and have OpenType features which can be used to move notes up and down, and combine characters into "ligatures," etc.
But some of the music font requires an external json file for proper layout.
Bravura requires this file (and you can see it in the GitHub repo).
BravuraText does not require this file and is supposed to work in normal text editors.

So if an APub user opens a music PDF which was created with a music font which requires the json file - since APub does not use this json file much of the layout info is missing.
Unless the music PDF was created in another layout app which uses the "text" version of a font, it is just never even going to have a chance to work.

 

On 1/5/2022 at 11:49 AM, thomaso said:

If I create in APub a text frame with some glyphes of font Petrucci and export that from Affinity I would expect to get it opened correctly if opened in APub. (no matter wheather font export as subset or not). So it seems Affinity does not fully read its exported content of a reopened PDF. – While the OP's PDF shows "MacRomanEncoding" my test PDF shows "Identity-H" as encoding.

From another forum I found the following post which makes me wonder if Affinity can be able in general to open its PDF correctly or if Affinity is currently "just" lacking the mentioned mapping table or entry "/ToUnicode". – Wouldn't Affinity need this to export this .afpub as PDF / or is this part of the PDF-lib used by Affinity?

The encoding used is dependent on the PDF library creating the file.
The original file was created on a Mac, and the PDF library used is their Quartz PDF library.
They chose one of the four "standard" PDF encodings - MacRomanEncoding.
And the font supports that encoding (in the cmap table inside the font).
So the Mac user's keyboard input works as expected.

Some PDF libraries just default to Identity-H whether it is needed or not.
And in a way this can be more cross-compatible.
A PDF library on Windows could have set the embedded encoding to WinAnsiEncoding (also in the cmap table).

But as Walt mentioned above, APub just does not like symbol fonts (or to put it another way, non-Unicode fonts) and does not support importing them.

On 1/5/2022 at 11:49 AM, thomaso said:

Aside the glyph mapping: what influences the tracking presented by APub when it opens its PDF? I guess a glyph mapping never would include tracking (but kerning only from the font file) and in particular not such extreme values like -300 instead of +150.

Any PDF editing application opening a PDF as text is guessing at the character spacing.
Some apps guess better than others.
There is no tracking info on the text in the PDF. No kerning info, etc.
PDF writing apps will often simply leave out the spaces (no space character is there) and just place the characters on the page at various coordinates. Some gaps in the text are actually coded as a space character (0020), some are simply gaps in where the characters are placed.
This is why we sometimes see some "spaces" disappear on import. There is nothing there.
Apps guess where the spaces should go by using some internal gap guessing measurements.

So the tracking settings are also just a guess, and often that guess is quite bad.

[kenmcd]

8 hours ago, Lagarto said:

(but if so, it is odd that Ghostscript can convert to curves embedded uninstalled fonts within a PDF file). 

The "curves" are already there.
Ghostscript is just changing the type of object from text to an image.
And dropping all the other info other than the coordinates and the contours of the image.

 

5 hours ago, Lagarto said:

I think that Adobe Illustrator fully supports embedded fonts, but you cannot open OP's file there for editing (while retaining text as font), either, even if you have the font installed. I think it is related to embedded font having been encoded in a way that cannot directly be mapped to installed fonts, and that Illustrator (at least CS6) does not even offer options to map the font. Whether this is dependent on custom encoding of a subset font, or that of a symbol font, I have no idea.

I think that is a decision based on what is practical.
The info to map the characters to the font is available, so they could do it.
But IL and PS both open PDFs as images (a bunch of curves).
This may be a practical decision. If the PDF does not have tags, or their hidden round-trip info, just place the files as curves.
Avoids all the encoding issues.
And like in this case, avoids having to explain why editing this file would never work.

Affinity added the pass-through option because of all the problems.
And perhaps they cannot seem to figure-out even normal Unicode font embedding.

 

[lacerto]

1 hour ago, LibreTraining said:

Ghostscript is just changing the type of object from text to an image

I am not sure what you mean? Ghostscript does convert fonts to outlines (it does not rasterize, and it does not use an already existing conversion).

Original with fonts:

Wienerwald.page1.pdf

Flattened with Ghostscript (using PDF Output Preview):

Wienerwald.page1_nofonts.pdf