Opened 12 years ago

Closed 8 years ago

Last modified 2 years ago

#141 closed defect (wontfix)

Wrong "Umlaute" in PDF-Document-Information

Reported by: guest Owned by: Eugene Romanenko
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 8 years ago.

Download all attachments as: .zip

Change History (15)

comment:1 Changed 11 years ago by Silvan Scherrer

Milestone: 1.3

comment:2 Changed 10 years ago by Silvan Scherrer

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

comment:3 Changed 10 years ago by Silvan Scherrer

see also ticket:143 for more information

comment:4 Changed 10 years ago by Silvan Scherrer

Milestone: and further

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

comment:5 Changed 10 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 8 years ago by Silvan Scherrer

Priority: majorFeedback Pending

please try if works

Last edited 8 years ago by Silvan Scherrer (previous) (diff)

comment:7 Changed 8 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 8 years ago by Batchheizer (previous) (diff)

Changed 8 years ago by Batchheizer

Attachment: TestGreek.pdf added

comment:8 Changed 8 years ago by Silvan Scherrer

i see the same. so i take care on it

comment:9 Changed 8 years ago by Silvan Scherrer

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

comment:10 Changed 8 years ago by Silvan Scherrer

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 8 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 8 years ago by Silvan Scherrer

Resolution: wontfix
Status: newclosed

closing this ticket in favour of

comment:13 Changed 5 years ago by Lewis Rosenthal

Milestone: 2.0 and furtherFuture

Milestone renamed

comment:14 Changed 2 years ago by Gregg Young

Milestone: Future1.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.