Opened 11 years ago

Closed 6 years ago

Last modified 12 months ago

#141 closed defect (wontfix)

Wrong "Umlaute" in PDF-Document-Information

Reported by: guest Owned by: eros2
Priority: Feedback Pending Milestone: 1.4.0
Component: Plugin: PDF Version:
Keywords: Cc:


German Umaute in PDF-Files are displayed wrong in the document-information-window. Even if they are set under OS/2 (PDFMergeNX or ExitTool?).

Attachments (1)

TestGreek.pdf (15.1 KB) - added by Batchheizer 7 years ago.

Download all attachments as: .zip

Change History (15)

comment:1 Changed 10 years ago by diver

  • Milestone set to 1.3

comment:2 Changed 9 years ago by diver

this is due to not having unicode support in the PM interface

comment:3 Changed 9 years ago by diver

see also ticket:143 for more information

comment:4 Changed 9 years ago by diver

  • Milestone changed from 1.3.1 to 2.0 and further

moved to 2.0 is this means a major work on the PM interface

comment:5 Changed 9 years ago by Batchheizer

Maybe it is no Unicode-Problem. It seems to be a "simple" code-page problem (1251 or so). Why? "Umlaute" are displayed wrong and not as "Häuschen". For Example "ü" gets a "³" or so. This can be converted to 850. So no Unicode-problem. This is different to the Greek headlines-problem.

comment:6 Changed 7 years ago by diver

  • Priority changed from major to Feedback Pending

please try if works

Last edited 7 years ago by diver (previous) (diff)

comment:7 Changed 7 years ago by Batchheizer

Check for QPDFView: QPDFVIew displays Hebrew correct in "Layout"/Gliederung and Eigenschaften. Greek is not correct. Maybe some accents are missing in Workplace Sans?

Last edited 7 years ago by Batchheizer (previous) (diff)

Changed 7 years ago by Batchheizer

comment:8 Changed 7 years ago by diver

i see the same. so i take care on it

comment:9 Changed 7 years ago by diver

when i understood Alex Taylor right this is a limitation of Workplace Sans.

comment:10 Changed 7 years ago by diver

attached is a small discussion with alex.

[17:15:20] <altsan> Hebrew gets replaced by a generic Unicode font (probably TNR WT J)
[17:15:31] <altsan> But Greek tries to display in Workplace Sans and only gets a handful of characters.
[17:15:54] <altsan> It all depends on how QT is checking the font for character support.
[17:15:57] <_divercust> so is it a WPSU problem? or 
[17:16:25] <altsan> Not exactly a WPSU problem, more like a flaw in the way QT4 and WPSU are interacting.
[17:17:36] <altsan> QT is presumably identifying the string as "Greek", then checking to see if the font supports "Greek" and deciding that it does.
[17:17:54] <altsan> Whether that's a flaw in how QT does the check, or in what WPSU is reporting, it's hard to say.
[17:18:35] <altsan> I know that's not quite what I said the last time, but I had time to think about it more after the conversation.  (I do remember that now.)
[17:19:59] <altsan> I /probably/ should make sure WPSU doesn't include Greek codepages in its header.  (Don't recall right now if it does or not.)
[17:20:33] <altsan> But I don't know if QT (via Freetype, I suppose) is checking the font's codepage flags, or looking for Unicode ranges.
[17:22:25] <altsan> If the former, that's something that should be fixed in WPSU.
[17:22:36] <altsan> If the latter... it's more complicated.

comment:11 Changed 7 years ago by ataylor

Following up to the above... the WPSU header reports support for the specific Greek codepages 1253 and 869. That is actually correct, because it /does/ support all the Greek characters in those codepages.

Something in QT4 (possibly Pango?) is somehow drawing the conclusion that WPSU supports the entire Greek Unicode block, which is wrong. Whether it's basing that conclusion on the fact that those two codepages are supported, or because it checks the font for some particular character (or range of characters), I don't know.

comment:12 Changed 6 years ago by diver

  • Resolution set to wontfix
  • Status changed from new to closed

closing this ticket in favour of

comment:13 Changed 4 years ago by lewisr

  • Milestone changed from 2.0 and further to Future

Milestone renamed

comment:14 Changed 12 months ago by gyoung

  • Milestone changed from Future to 1.4.0

Move closed tickets to completed milestone. Many of these were completed before 1.4.0

Note: See TracTickets for help on using tickets.