Wrong characters when editing text

[petepuma01]

Please review the attachment. When we edit text, some of the characters we type on the keyboard are not what is shown in the document. For example, if I type in "KPMG", in one section it comes out as "BGDG" while another section shows "BGMG". Why are the incorrect characters shown?

We have tried this on two different PCs, one running 8.339 and the other running 8.341.

Wrong Characters.pdf

(151.66 KiB) Downloaded 49 times

[Willy Van Nuffel]

It seems like some specific fonts have been used in the PDF-document. Fonts that are not available by default on each computer.
In that case, these fonts are (partially) embedded in the PDF. You can see this (when the PDF is open) via File > Document Properties > Fonts. They are show at the right like "Embedded Subset(s)".

Each textbox (visible as a rectangle when editing the text) has its own "subset" of characters. Characters that have been used for the text in that textbox.

This means that (most of) the characters that NOT have been used in the already existing text in that textbox, can NOT be used for adding new text into that same textbox.

Using the "File > Save As Optimized"-feature can help in these circumstances, because different subsets for the same font can be merged. So, missing characters in one section can become available for the other section.

Please give it a try and let us know if this works for you.

Best regards.

[TrackerSupp-Daniel]

Hi all,

Thanks for the solid answer Willy!
Petepuma01, please do let us know if this helps you at all.

Kind regards,

[petepuma01]

Thanks Willy. Good explanation. Unfortunately, it did not work for me. As an example, an upper case K changes to a B. I reviewed the document and nowhere else was there an upper case so the merge had nothing to re-use.

[Willy Van Nuffel]

Thanks for your feedback.

A solution could be to select and change the text in the PDF to a font that is installed and available on each computer.
So, "all" the characters included in that font will become available.
In case it goes about an isolated word in the text, like in your example "KPMG", you can just change the font for that word only.

In the future, when using specific fonts, try to embed them completely while creating the PDF - if possible - not as a subset.

Regards.

EDITED.

[TrackerSupp-Daniel]

[Timur Born]

Also take notice that the document is using Type1 fonts. If you print this to a new PDF file Editor will discard the font information entirely and instead draw a new font that does not link displayed letters to keyboard characters anymore. So watch out for that, too.

[Timur Born]

I took a look at the document and suspect the behavior to be an Editor bug.

The are "K" and "M" characters embedded in the font, but Editor allows to only use characters that are part of the current text paragraph. So even when the "K" is written in the same exact font and size in one paragraph of the same text box it still cannot be edited in another paragraph unless it is copied and pasted from the working paragraph. Once the copy&paste is done it can be used/typed as expected to the right of the copied text (even after deletion).

Here is an example where I typed "KPMD", but Editor turned it to "BPDD", with the last "D" looking different in size.

Then I copy & pasted "KPA Risk M" from the last paragraph, which enabled me to type a proper "KPM" line to the right of the copied text.



I suspect these to be Type1 shenanigans within Editor, but others may offer more insight. Font properties for both sections (working and non working) are exactly the same according to Editor.

[TrackerSupp-Daniel]

Hi, Timur Born

The issue here is not with using the fonts that are available, the issue is within how the font subsets are split. As you can see from looking at the fonts in the document properties, the minionPRO and SlatePRO fonts are both broken apart into multiple subsets with different object numbers. We can make use of a subset which exists within the current text block as those subsets are associated, but other subsets, outside this text block could just as well be a completely different font. Until you copy them and they exist in the same location with the same name, they do not overlap and are kept as separate entities.

The same issue would occur with non type-1 fonts if they too were split apart like this. To resolve the issue, you would need to either fully embed the fonts within the document, or use a font which natively exists on the target devices (usually windows).

Kind regards,

[Timur Born]

Should the fonts properties point at what is going on then to make better user decisions? As far as I can see font properties from both sections of the text body look exactly the same, no hint about using different splits of the same font.

I also wonder if it should not be possible to automatically join those splits back together if they share the same font properties anyway?

[TrackerSupp-Daniel]

Hi, Timur Born

As far as the human eye can see, yes, those fonts are identical, but they are only a subset, meaning an incomplete set of the font data. To a computer, there is a world of difference between each subset, even if they are for the same base font.

As such, joining subsets back together is a very difficult prospect, to begin with, we cannot be certain that an item in a font is correct.

Just as an example, (simplified for ease of explanation), say that a normal Arial font maps the QWERTY keys to the correct buttons on your keyboard, we will give these keys the "ID's" Q=1, W=2, E=3, R=4, T=5, Y=6.
Visually, you may see QWERTY, but the computer sees 123456[Arial font package 1], and knows from the font information in package 1 that 123456=QWERTY and displays it properly.
Once that is determined, and the text is shown correctly, those ID numbers are then assigned the association to the key on the keyboard, so that pushing the Qkey = object 1 = visual Q.

Oftentimes, subsets will take shortcuts, so while in our example here, you could extrapolate, that if QWERTY = 123456, obviously UIOP should then = 7,8,9,10 (example, not precisely real handling). Except that extrapolation would be wrong. That is because you typed the sentence like this:
"QWERTY are the first..."
Since "[space]", "a", "r", etc. do not have IDs, we have to locate the next available (unassigned) item in the sequence, but the sequence does not exist becuase this subset took a shortcut. Instead we say "okay, [space]=7, the a key = 8. Then we do the same to r, "okay r does not have anything assigned to it already, r = 9.
The issue now, is that "a = 8 = a", but in the font subset we are using, 9 = b (not "r"), 10 = c (not e), and the issue is then expanded.
The sentence, to the computer reads like this (yes the 7's are spaces
"1,2,3,4,5,4,6,7,8,9,10,7,11,12,10,13 "...etc.
Which visually to us is instead
QWERTY abc dec"...etc

I created a very basic visual representation of what I have explained here, and hope that it helps to explain how some fonts can work when acting improperly.

Unfortunately, there is not much we can do in this case, because as far as we know, we are handling the font as it wants to be handled.

When this happens, you might have two separate subsets who both claim that the first 5 letters they provide, have the IDs 12345, despite being the same font. If we disregard one in favor of the other, it would break any sections in which there was a conflict.

As I have said in the past on posts handling this topic, everything I have just iterated was explained to me by our dev team in front of a whiteboard with numerous diagrams. I have explained the best I can, so there will be no further elaboration to questions like "well, why cant you just do this..?" as honestly, I personally do not know, but the dev team have clearly stated that nothing can be done if the font is taking these shortcuts.

Kind regards,

[Timur Born]

I understand that automatic joining of different sub-sets is not (easily) possible. But I still wonder if the font properties should not reveal to the user that different sub-sets are used for different paragraph.

From a user's perspective both paragraphs used exactly the same font, there was no hint at any underlying differences. Would be nice if sub-sets were identified as part of the font properties display.

[Tracker Supp-Stefan]

Hello Timur Born,

Usually when different subsets are used - they will have unique names. So it is possible to see those in the preferences of the document, but this would actually probably only add to the complexity of the situation and is not something that we expect everyone to know or be able to check.

The thing is that fonts should ideally be embedded wholly if they are not CJK Fonts (which are huge) as the space savings are minimal, and the possible complications further down the line are much more severe - as in the current case, but the PDF specification does allow partial embedding of fonts, and when this happens - these are the results!

Kind regards,
Stefan

[Timur Born]

In the example PDF the fonts/subsets in the different paragraphs did not show as different names in the fonts properties panel. There was no way to discern which was used, even less so after copy & paste from one paragraph to the other. You would get a "K" in one paragraph and a "B" in another, with both paragraphs showing the very same font properties.

This is something that Editor could improve on, making it possible to discern sub-sets while editing.

[Tracker Supp-Stefan]

Hello Timur Born,

I could not notice the sample earlier, but in most cases the font susets are names e.g. "Arial-AYQYF", "Arial-GAQPB" and the like, but in this sample indeed there was no way to discern between the subsets. Sure - I will check with our devs to see if any improvements could be done here.

Kind regards,
Stefan