No Thumbnail creation for PDF-Files with Umlauts (äöüÄÖÜß)

Ask for help and post your question on how to use XnView Classic.

Moderators: XnTriq, xnview

Post Reply
Alberto
Posts: 5
Joined: Mon Dec 09, 2013 3:23 pm

No Thumbnail creation for PDF-Files with Umlauts (äöüÄÖÜß)

Post by Alberto » Mon Nov 02, 2015 4:26 pm

Hello to all,

I use XnView 2.34 with Ghostscript (both from portableapps.com).

PDF Thumbnail creation works fine until there is a German Umlaut (äöüÄÖÜß) in the Filename, then it fails.

Is there a solution / fix for this problem ?

(renaming to non-umlaut characters is not an option)

cday
XnThusiast
Posts: 2433
Joined: Sun Apr 29, 2012 9:45 am
Location: Cheltenham, U.K.

Re: No Thumbnail creation for PDF-Files with Umlauts (äöüÄÖÜ

Post by cday » Mon Nov 02, 2015 4:36 pm

Alberto wrote:I use XnView 2.34 with Ghostscript (both from portableapps.com).
PDF Thumbnail creation works fine until there is a German Umlaut (äöüÄÖÜß) in the Filename, then it fails.
XnView 'Classic' doesn't support Unicode characters...
Alberto wrote:Is there a solution / fix for this problem ?
You can use XnViewMP, still in beta, if it supports the functions you need...

Note:

Ghostscript must be x64 if you use XnViewMP x64, and some menu items have been moved...

Alberto
Posts: 5
Joined: Mon Dec 09, 2013 3:23 pm

Re: No Thumbnail creation for PDF-Files with Umlauts (äöüÄÖÜ

Post by Alberto » Mon Nov 02, 2015 5:36 pm

cday wrote:
Alberto wrote:I use XnView 2.34 with Ghostscript (both from portableapps.com).
PDF Thumbnail creation works fine until there is a German Umlaut (äöüÄÖÜß) in the Filename, then it fails.
XnView 'Classic' doesn't support Unicode characters...
But for .jpg Files it works fine, no Problem with Umlaut-Characters... how's that then ?

I suspect Ghostscript in that case. Maybe there is a setting for that... ?
cday wrote:
Alberto wrote:Is there a solution / fix for this problem ?
You can use XnViewMP, still in beta, if it supports the functions you need...

Note:

Ghostscript must be x64 if you use XnViewMP x64, and some menu items have been moved...
Is there a portable Version (MP & GS 64 Bit) because I have to use portable Software ?

I will have a look at MP if there is surely no solution for classic which I like quite more.

cday
XnThusiast
Posts: 2433
Joined: Sun Apr 29, 2012 9:45 am
Location: Cheltenham, U.K.

Re: No Thumbnail creation for PDF-Files with Umlauts (äöüÄÖÜ

Post by cday » Mon Nov 02, 2015 6:09 pm

Alberto wrote:But for .jpg Files it works fine, no Problem with Umlaut-Characters... how's that then ?
You did say you are using the portableapps.com version of XnView 2.34, presumably that version has Unicode support...
I suspect Ghostscript in that case. Maybe there is a setting for that... ?
I'm not sure about the portableapps.com version, you could check their literature or post on that forum...

Ghostscript itself supports Unicode, as the installed version of XnViewMP opens PDF files with umlauts and similar characters normally.
Is there a portable Version (MP & GS 64 Bit) because I have to use portable Software ?
XnViewMP and other XnView software ZIP versions can be used as portable software although with some limitations; I recently requested to add Ghostscript support for XnView 'Classic' when it is used as portable software, but the modified version didn't work... :(

A while back I searched the portableapps.com site and found a post indicating that Ghostscript support had been added for an earlier version of XnView, but I couldn't get it to work with the later version I was using, possibly my fault...

Alberto
Posts: 5
Joined: Mon Dec 09, 2013 3:23 pm

Re: No Thumbnail creation for PDF-Files with Umlauts (äöüÄÖÜ

Post by Alberto » Thu Nov 05, 2015 2:56 pm

cday wrote:You did say you are using the portableapps.com version of XnView 2.34, presumably that version has Unicode support...
If it had Unicode support Umlauts should be no problem, should they ;-)

I still think that there is a (Unicode?-) problem with Path/Filename transfer to Ghostscript where it simply cannot find the file. With pictures (internal) it works, with PDF (external) not...
cday wrote:XnViewMP and other XnView software ZIP versions can be used as portable software although with some limitations; I recently requested to add Ghostscript support for XnView 'Classic' when it is used as portable software, but the modified version didn't work... :(
Just try the ones from Portable Apps: XnView Portable and Ghostscript Portable. They work fine together.

I tried XnViewMP which seems to have evolved. I am still testing it and hope it will be useable in this Beta-State (I had 2 crashed while testing...it really is still beta! :-( On the plus side it is also available for Linux :-)

Subjektiv
Posts: 18
Joined: Fri Feb 12, 2010 10:41 am

Re: No Thumbnail creation for PDF-Files with Umlauts (äöüÄÖÜß)

Post by Subjektiv » Mon Apr 09, 2018 9:24 am

XnViewMP (and XnView) does not make thumbnail pictures from PDFs with äöüÄÖÜ in filenames stored on harddisk A:
But it does for all files in other disks (e.g. D: C: G: H:)
Maybe it is a problem of Ghostscript (have newest version)

Any Idea?
Thanks

User avatar
xnview
Author of XnView
Posts: 33337
Joined: Mon Oct 13, 2003 7:31 am
Location: France
Contact:

Re: No Thumbnail creation for PDF-Files with Umlauts (äöüÄÖÜß)

Post by xnview » Thu Apr 12, 2018 12:52 pm

Subjektiv wrote:
Mon Apr 09, 2018 9:24 am
XnViewMP (and XnView) does not make thumbnail pictures from PDFs with äöüÄÖÜ in filenames stored on harddisk A:
But it does for all files in other disks (e.g. D: C: G: H:)
Maybe it is a problem of Ghostscript (have newest version)
yes really strange, i don't understand why it works on other drive. NTFS?
Pierre.

User avatar
XnTriq
Moderator & Librarian
Posts: 5574
Joined: Sun Sep 25, 2005 3:00 am
Location: Ref Desk

Ghostscript & Unicode

Post by XnTriq » Fri Jan 03, 2020 3:30 pm

My setup: XnView v2.49.1 + Ghostscript v9.21 for Windows (32 bit)

XnView's browser displays generic file-type icons for PDF, EPS, and AI files with unicode characters (umlauts etc.) in their filename.
Windows Explorer → Send To → XnView wrote:Format of the file <goüjelée.pdf> could not be determined

Related reports:

User avatar
xnview
Author of XnView
Posts: 33337
Joined: Mon Oct 13, 2003 7:31 am
Location: France
Contact:

Re: Ghostscript & Unicode

Post by xnview » Mon Jan 13, 2020 9:31 am

I can't reproduce, the unicode filename is shown as short name (with ~), and i can view it
Pierre.

User avatar
XnTriq
Moderator & Librarian
Posts: 5574
Joined: Sun Sep 25, 2005 3:00 am
Location: Ref Desk

Re: No Thumbnail creation for PDF-Files with Umlauts (äöüÄÖÜß)

Post by XnTriq » Mon Jan 13, 2020 4:45 pm

I'll update to XnView v2.49.2 and Ghostscript v9.50.

https://www.ghostscript.com/doc/current/History9.htm#Version9.04 wrote:
Experimental Unicode/UTF8 Support on Windows

This release introduces some experimental build-time optional support for UNICODE pathnames on Windows. Essentially this works by following the model that Linux (and MacOS) have followed for years.

If this code is enabled, then the way ghostscript handles command lines, registry settings, file accesses and other api calls with top bit set characters in (i.e. codes >= 128) will change. The net benefit of this change is that ghostscript will now be able to cope with accessing files with unicode characters (i.e. codes >= 256) in their pathnames.

This behavior is all completely transparent to users, with the exception of those calling the gsapi functions with strings including 'extended ascii' (i.e. characters with codes >= 128 and <= 255). These characters include accented latin characters, such as u + umlaut, a + grave etc. The changes required for code that is affected by this are relatively minor, but as this is a change to the current API, we are announcing it in advance, and inviting comments.

As of the 9.04 release, the code is disabled. For those who wish to experiment you will need to build Ghostscript from source, and either pass USEUNICODE=1 when you invoke nmake or edit psi/msvc.mak to remove the /DWINDOWS_NO_UNICODE option from CFLAGS.

WARNING: Our intention, subject to feedback, is to enable this by default in near-future releases (hopefully, the next major release). If you make use of the affected APIs you should be prepared for the change to occur - be aware, however, that the current code is experimental and, depending on the feedback we get, maybe subject to change.

NOTE: this whole change refers to file paths, command line parameters and so on - it does not imply that we have unilaterally extended Postscript to understand UNICODE.

More details:

To give an example, suppose we have a file 'EXAMPLE' we'd like to invoke ghostscript on, where 'EXAMPLE' is actually a string that contains some characters with codes >= 128.

On Linux (or MacOS X), when ghostscript is called from a shell, e.g.

gs EXAMPLE

the command is UTF8 encoded; this means that characters with codes < 128 are left unchanged, and characters >= 128 are encoded into multiple bytes. This encoded string is then passed to the standard 'main' entrypoint in the gs executable.

Ghostscript proceeds internally without any special handling of these multibyte characters at all. When it comes to access files it therefore passes out the UTF8 encoded strings to the standard OS file handling routines. These routines are designed to take pathnames in UTF8 format, and thus the files are accessed as normal.

If the Ghostscript executable outputs these (or other) strings to its stdout, the shell again converts the output from UTF8 back to unicode in order to display it.

The net effect is that the caller can seamlessly pass in unicode filenames, has his fileaccesses work out and gets unicode output without the core of ghostscript ever having to worry about it.

The code change discussed here endeavours to make Windows follow the same pattern as closely as possible.

When Windows executables are invoked, they can either be called through an 'ascii' entrypoint (main), or through a unicode ('wide') entrypoint (wmain). The difference is invisible to the caller, except that unicode executables can accept characters >= 256 in their invocations.

The new code changes ghostscript from being an ascii executable to being a unicode one. The Windows specific outer layer takes the unicode command string and UTF8 encodes it before passing it to the ghostscript core.

Similarly, the Windows specific filing system calls are updated to accept utf8 encoded strings from the core, and to convert them to unicode before operating on them.

The Windows gui app (gswin32.exe, NOT gswin32c.exe) is also updated to convert stdin/stdout between unicode and utf8 as appropriate, allowing unicode strings to be copied/pasted to/from other apps.

All of this should be completely transparent to the user, and no code changes should be required. The one area where changes may be required are where ghostscript is invoked through the gsapi functions.

Currently, on Linux (and MacOS X) any strings sent over the gsapi are assumed to be utf8 encoded (and thus can represent any Unicode character). On Windows, they are assumed simply to be in extended ASCII (and can therefore represent any character < 256 in the current codepage). With the proposed change, Windows will move to be in step with Linux. No differences will be caused to anyone who only uses chars <= 128, but those people using character codes between 128 and 256 (or indeed wanting to use higher codes) will need to utf8 encode the strings before calling gsapi functions.

Such encoding/decoding is a very simple process, and code for both directions can be found in psi/dwmain.c, psi/dwmainc.c and psi/dwtext.c.

Again, we welcome feedback on this feature, in this case problems or suggestions about the implementation can be submitted via Bugzilla but for detailed discussion about the approach for which we opted, it would be more beneficial discuss it (preferably) on our IRC channel #ghostscript on freenode.net, or on the gs-devel mailing list.

User avatar
XnTriq
Moderator & Librarian
Posts: 5574
Joined: Sun Sep 25, 2005 3:00 am
Location: Ref Desk

Re: No Thumbnail creation for PDF-Files with Umlauts (äöüÄÖÜß)

Post by XnTriq » Mon Jan 13, 2020 6:00 pm

Here's an example of the kind of files (e.g. x_12E.tmp) created in the %TEMP% directory of my Windows system when XnView's browser is generating thumbnails of PDF files:

Code: Select all

%!PS-Adobe-3.0
%%DocumentMedia: y3000x4000 4000 3000 70 white ()
%%Pages: 1
%%EndComments
%%BeginProlog
/Page null def
/Page# 0 def
/PDFSave null def
/DSCPageCount 0 def
/DoPDFPage {dup /Page# exch store pdfgetpage pdfshowpage } def
GS_PDF_ProcSet begin
pdfdict begin
%%EndProlog
%%BeginSetup
(X:\\Test\\Sample.pdf) (r) file { DELAYSAFER { .setsafe } if } stopped pop
 pdfopen begin
 process_trailer_attrs
%%EndSetup
%%Page: 1 1
%%PageMedia: y3000x4000
1 DoPDFPage
%%Trailer
currentdict pdfclose
end
end
end
%%EOF

User avatar
XnTriq
Moderator & Librarian
Posts: 5574
Joined: Sun Sep 25, 2005 3:00 am
Location: Ref Desk

Re: No Thumbnail creation for PDF-Files with Umlauts (äöüÄÖÜß)

Post by XnTriq » Thu Jan 16, 2020 9:00 pm

XnTriq wrote:
Mon Jan 13, 2020 4:45 pm
I'll update to XnView v2.49.2 and Ghostscript v9.50.
Updating to the latest versions fixed the issue :-)

Post Reply