Jump to content

Recommended Posts

Posted

After indicating that fonts are available, AD replaces common characters with blank substitutions. Note the pdf imports fine into Inkscape and libreoffice. Converting the image to SVG in Inkscape and opening in AD works. Not the kind of workflow steps expected for the program. Note the original file was exported from RStudio. The version attached was printed to PDF on macOS - an attempt at encapsulating the data in the hopes of better import to AD - results were the same.

fig5_8.pdf

Posted

Hi @DWALKER and welcome to the forums,

Although Symbol is recognised as being the font used, font manager suggests that some unsupported characters are used in the document... It appears to be unhappy with the mathematical symbols used for some reason, parentheses, commas and equals signs...

I think the issue is that Affinity is seeing the font as being the version of Symbol built in to the OS rather than the version actually used in the document...

973698855_FontManager.png.e6445c09289458b547c4f24c54d0c7b5.png

Affinity Designer 2.6.0 | Affinity Photo 2.6.0 | Affinity Publisher 2.6.0
Affinity Designer 2.6.2 (3213) Beta | Affinity Photo 2.6.2 (3213) Beta | Affinity Publisher 2.6.2 (3213) Beta

MacBook Pro M3 Max, 36 GB Unified Memory, macOS Sonoma 14.6.1, Magic Mouse
HP ENVY x360, 8 GB RAM, AMD Ryzen 5 2500U, Windows 10 Home, Logitech Mouse

Posted
8 minutes ago, Hangman said:

... I think the issue is that Affinity is seeing the font as being the version of Symbol built in to the OS rather than the version actually used in the document...

But, this seems to me as a macOS specific problem. The pdf opens correctly in the Affinity apps for Windows.

MAC mini M4 | MacOS Sequoia 15.3.2 | 16 GB RAM | 256 GB SSD 
AMD Ryzen 7 5700X | INTEL Arc A770 LE 16 GB  | 32 GB DDR4 3200MHz | Windows 11 Pro 24H2 (26100.3476)

Affinity Suite V 2.6.1  & Beta 2.6 (latest)
Interested in a free (selfhosted) PDF Solution? Have a look at Stirling PDF

I already had a halo, but it didn't suit me!

Posted
49 minutes ago, Komatös said:

But, this seems to me as a macOS specific problem. The pdf opens correctly in the Affinity apps for Windows.

Agreed, I think on mac the Symbol font is being confused with the Emoji & Symbols which form part of the OS...

Affinity Designer 2.6.0 | Affinity Photo 2.6.0 | Affinity Publisher 2.6.0
Affinity Designer 2.6.2 (3213) Beta | Affinity Photo 2.6.2 (3213) Beta | Affinity Publisher 2.6.2 (3213) Beta

MacBook Pro M3 Max, 36 GB Unified Memory, macOS Sonoma 14.6.1, Magic Mouse
HP ENVY x360, 8 GB RAM, AMD Ryzen 5 2500U, Windows 10 Home, Logitech Mouse

Posted
1 hour ago, DWALKER said:

Note the original file was exported from RStudio.

So for some reason RStudio is using a font named Symbol for the , = ( ) glyphs instead of using the ones in Helvetica.

Mac Pro (Late 2013) Mac OS 12.7.6 
Affinity Designer 2.6.0 | Affinity Photo 2.6.0 | Affinity Publisher 2.6.0 | Beta versions as they appear.

I have never mastered color management, period, so I cannot help with that.

Posted

Ok. Makes sense (or the explanation does), there will be some symbol elements used since it is a math 'equation'. I suspect the '=' is being treated as an equation element when being rendered. The characters are being added using a function similar to bquote(), which allows for formatted text in figure annotations. Presumably Inkscape doesn't have the issue because it is less OS aware? I do find it strange that Inkscape is fine and also the import dialog for AD says all fonts are available (doesn't report the error shown in the font manager). The SVG workaround does work. Extra step in Inkscape.

Posted

@DWALKER You do not say what OS was used for the original file.

But the Symbol font is problematic on both operating systems.

On Windows the Symbol font is an actual old symbol font (e.g. pre-Unicode).
APub only works with Unicode fonts, with Unicode encoding.
APub cannot read how it got embedded (we could look if you provide the PDF file).
So APub cannot import the characters properly.

On macOS the Symbol font is a Unicode font, but that is not how it was embedded.
In your macOS-generated sample PDF above the Symbol font is embedded with Mac Roman encoding.
APub does not understand the old Mac Roman encoding (which is kinda dumb).
So again APub cannot import the characters properly.

Not sure what Inkscape is doing (have to see the SVG).
But this was an issue in LibreOffice years ago and Inkscape may have done a similar work-around.
LibreOffice (LO) had problems with round-tripping Word files which included bulleted lists because Word/Windows was using this non-Unicode Symbol font for the bullets. So when the doc was opened in LO on Linux it would fail because there is no old Symbol font in Linux. They did some sort of work-around back then - perhaps Inkscape has done something similar. Have to see the SVG to see what they did.

Linux, macOS, and Windows all include Unicode "math" fonts which include those characters.
You may want to submit an issue/request with RStudio to fix this.

 

Posted

Thanks so much for this. I didn't realize Apple still has an old Mac roman encoded font. There is 'symbol' - which is the offending font (from what I can tell) and "Apple Symbol" which appears to be, dare I say, 'Unicode Standard'. The default font choices in plotmath which is the annotation markup used in R, and part of the graphic driver package, seems to load the older font preferentially. There is a similar issue (so I see from Google) on the Windows side with an old symbol font. Perhaps AD can handle that issue for Windows users. Regardless, and in case any other R users want to use AD in their workflow: I was able to fix the font issue using cairo_pdf(). The standard instructions of 'just' using this function to automatically embed the font did not work. I had to specifically substitute by selecting 'Apple Symbol' font with the argument  symbolfamily=cairoSymbolFont("Apple Symbols", usePUA=FALSE). A similar (although not identical) fix can be implemented on Windows should the issue arise. The more "modern" font imports into AD and works fine now.

I will say in terms of AD: the PDF import dialog is a bit misleading insofar as it indicates all fonts are present (they are but don't work entirely). Once opened, the Resource Manager shows an exclamation for the font. So it is clear the issue is detected (at least at some point while opening the file). So a warning in the import dialog would help - a quick check for modern encoded TTF fonts and a brief 'may be a problem' message on fail.  With what otherwise seemed like a normal import process and correct import into opensource solutions, I figured it was an AD rendering issue. Thanks again.

Posted
32 minutes ago, DWALKER said:

I didn't realize Apple still has an old Mac roman encoded font. There is 'symbol' - which is the offending font (from what I can tell) and "Apple Symbol" which appears to be, dare I say, 'Unicode Standard'.

As I mentioned above, it is a Unicode font. So it is quite odd that it got embedded in the PDF as Mac Roman encoding. I looked inside the font and the only old code page listed was Latin 1252. So my guess is it must be the app or the Mac Quartz PDF library which is designating/defaulting to Mac Roman.

Given the ubiquitous nature of the old Mac Roman encoding (freaking everywhere in old docs) it really is dumb that APub cannot read it. If you open an old Mac Roman encoded doc in Word or LibreOffice or InDesign etc., it converts it to Unicode and off you go. And the conversion is simple. Dumb.

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.