#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: |
Description
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)
Change History (15)
comment:1 by , 15 years ago
Milestone: | → 1.3 |
---|
comment:2 by , 15 years ago
comment:4 by , 15 years ago
Milestone: | 1.3.1 → 2.0 and further |
---|
moved to 2.0 is this means a major work on the PM interface
comment:5 by , 15 years ago
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 by , 12 years ago
Priority: | major → Feedback Pending |
---|
please try if ftp.netlabs.org/pub/qtapps/qpdfview.zip works
comment:7 by , 12 years ago
Check for QPDFView: QPDFVIew displays Hebrew correct in "Layout"/Gliederung and Eigenschaften. Greek is not correct. Maybe some accents are missing in Workplace Sans?
by , 12 years ago
Attachment: | TestGreek.pdf added |
---|
comment:9 by , 12 years ago
when i understood Alex Taylor right this is a limitation of Workplace Sans.
comment:10 by , 12 years ago
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 by , 12 years ago
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 by , 12 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
closing this ticket in favour of http://svn.netlabs.org/qt4/ticket/285
comment:14 by , 6 years ago
Milestone: | Future → 1.4.0 |
---|
Move closed tickets to completed milestone. Many of these were completed before 1.4.0
this is due to not having unicode support in the PM interface