The app Document Viewer does not show the file name of the document

Hardware Librem 5
1

The app Document Viewer does not show the file name of the document, but some internal Title. Look this screen shot and the top two thump nail pictures:

2025-01-07-064136
2025-01-07-064136720Ă—1440 96.6 KB

The names below the pictures do not reflect the name of the files, which is something like Taufkirchen-225bus.pdf (which is built by the name of my village and the number of the bus line #225, easy to remeber). It seems the app uses some internal information from the PDF file for example 472_000777, what I would count as a bad idea:

purism@pureos:~$ ls -l Documents/Tauf*225bus.pdf
-rw-r--r-- 1 purism purism 1024624 Dec 31 17:16 Documents/Taufkirchen-225bus.pdf
-rw-r--r-- 1 purism purism 1023741 Dec 31 17:18 Documents/Taufkirchen-Tela-225bus.pdf
purism@pureos:~$ strings Documents/Taufkirchen-225bus.pdf | grep 000777
  /Title (472_000777)
              <rdf:li xml:lang="x-default">472_000777</rdf:li>
              <rdf:li xml:lang="x-default">472_000777</rdf:li>

Any idea how this could be fixed by configuration of the Desktop file, for example.

2 Likes
2

It appears to be a known issue. (You can easily find numerous complaints on the web about this.) It is arguable as to whether it is a bug but polite software would give the user control over the hierarchy of caption information displayed e.g. you want filename first and “yeah, whatever” if it wants to display the Title too.

The web says that one workaround is to remove the Title property from the PDF file. My PDF-fu is non-existent so I can’t advise how easy or difficult that would be, and whether it could readily be automated.

I also wonder how it might handle a Title that is all spaces - because changing the Title to all spaces may be easier than removing it.

I don’t know how often you re-download these PDF files.

Another approach would be to ask the source of the PDF files either not to supply a Title or to supply a more meaningful Title - or at least to give an option for that.

1 Like
3

The supplier is the Munich Public Transport company. I guess, a change is impossible. Starts already with hunting for a person who understands my request :slight_smile:

I will modify it with an hex editor and make this string to something useful for me.

1 Like
4

I would just blank it out and see whether that solves the problem.

1 Like
5

I used vim -b ... and modified the line in both files to:

purism@pureos:~/Documents$ grep -a Tk_ Taufkirchen-Tela-225bus.pdf Taufkirchen-225bus.pdf
Taufkirchen-Tela-225bus.pdf:  /Title (Tk_Tela_225_bus)
Taufkirchen-225bus.pdf:  /Title (Tk_225_bus)

and they show up fine now.

2 Likes
6

As an aside, the main command line tool for setting the metadata in jpg and/or pdf files is exiftool.

e.g. To show the metadata: “exiftool filename.pdf”

e.g. To set the title: "exiftool -Title=“This is the title now” filename.pdf

See above.

2 Likes
7

Thanks. I installed sudo apt install libimage-exiftool-perl.

1 Like
8

Cool. I didn’t know that. I use exiv2 exclusively for setting (or getting) metadata in JPG and other image formats and it doesn’t do PDF and I haven’t had cause to do much with PDF files.

I have perhaps controversially changed the solution post in this topic from @guru’s to yours because I think exiftool is a significantly better solution than vi - as much as I love vi :wink:

Just a tip though … when presenting shell commands in this forum, if you don’t enclose the command in backquote characters then the double quotes are treated as smart quotes and get changed from real double quote characters into the respective Unicode asymmetric double quote characters (aka 66 and 99) and hence when someone copies and pastes the command into a shell window the command won’t work and has to be edited.

1 Like
9

This is wrong in the sense of a tested solution, at least I haven’t tested it. And I think the vim -b ... approach did it job finde for this small use case.

2 Likes
10

For the record, I did test the command given and confirmed that it works as advertised, before making the change. However I only tested it on a desktop Linux computer, not on the Librem 5 itself. I have no reason to think that the tool would work differently on the Librem 5 etc. but, as you imply, there is nothing like testing it in the original problem environment in order to confirm that it really solves the problem.

1 Like