PDF import changes rotation of a certain character in vertical writing mode

[Apep8472]

Given the attached PDF, an import in Affinity Designer 2.5.7 of the attached PDF changes the rotation of the "ー" character from vertical to horizontal. The left image is the correct one. This is very surprising, I assumed PDF would be safe to import for simple text.

 

-->

text.html.pdf

[MikeTO]

It is the correct Unicode character, but it's not rotated as it is in the PDF because Affinity doesn't support rotating individual characters at this time.

You'll see this if you place the PDF on a page rather than opening it. The character will be rotated when the PDF is set to Passthrough but when you change it to Interpret then the character will not be rotated.

I think the best option might be to use Find and Replace to change the character to a vertical bar.

[MikeTO]

There's something unusual about NotoSansJP but I don't know enough to start a thread or whether it's even an Affinity issue so perhaps somebody else knows more.

I installed the variable version from Google Fonts and I got a missing font notification when opening the PDF. This screenshot is from 2.6. Version 2.5.7 was similar except that the missing font name didn't have spaces in it. When I replaced the variable font with the static files, I did not get a missing font notification.

Also, when using the variable font, the Replacement Style list in the dialog was set to ExtraLight but the document uses SemiBold. I tried to change it to the right weight but it kept changing back to ExtraLight after selecting any other weight in both 2.5.7 and 2.6. Regardless, it used the correct weight when opening the document.

[kenmcd]

13 hours ago, Apep8472 said:

Given the attached PDF, an import in Affinity Designer 2.5.7 of the attached PDF changes the rotation of the "ー" character from vertical to horizontal. The left image is the correct one. This is very surprising, I assumed PDF would be safe to import for simple text.

That glyph was rotated/substituted using an OpenType feature (vert or vrt2).
And OpenType features do not transfer in a PDF.

Affinity does not support vertical text, and thus it does not support vert or vrt2.
So there is no way to apply vert or vrt2 to that character.

The original character is U+30FC
The substituted glyph is G+44FE
So you can highlight that character, and switch into Unicode mode,
and change it from U+30FC to G+44FE.

As I mentioned above, Affinity does not support vertical text, and does not support the OpenType features required to support vertical text.
So the only way to do this is manually.

 

[kenmcd]

11 hours ago, MikeTO said:

There's something unusual about NotoSansJP

In APub v2.5.7 on Win10 both static and variable fonts work fine. Get the no fonts missing message.

I know you are on Mac, and the VF font only has platformID 3 (Microsoft) names. Even Apple no longer requires platformID 1 (Mac) names. Some of the newer Apple only have platformID 3. 

GF was moving to platformID 3 only, but may have backtracked a bit on that. Some apps seem to need a few of the platformID 1 name fields, so some fonts have some of them.

So I am wondering if APub on the Mac is still having static-vs-variable name matching issues because the font has no platformID 1 names at all. We could compare to another font(s) that does work for you on Mac.

Affinity could help by simply answering that question - they are looking for the Mac names and that is the problem. 

Other notes...

NotoSansJP (no spaces) is in nameID 25 which was supposed to be a PostScript prefix for variable fonts in PDFs, but Adopey has been requiring it to be a unique name they are using to identify the separate VF fonts (i.e. Roman vs Italic). Not sure how it is used in the PDF dialog fonts list on your v2.5.7. 

Noto Sans JP only has two masters - Thin and Black. The default master is Thin. So sticking on ExtraLight makes no sense.

Bugs. 

Nothing wrong with the font (actually made by Adobe folks).

[stokerg]

Hi @Apep8472,

As others have stated, vertical text isn't currently supported.

@MikeTO and @kenmcd, i've logged the different behaviour between Mac and Windows with the variable version of the font and will update here with any comments i get on the report from the Developers