(In reply to Psycho Chicken from comment #0)

> This Tag is produced, when I convert a PDF version 1.4 to version 2.00 with
> 
> gs -dEmbedAllFonts=true -dSubsetFonts=false -dPDFSETTINGS=/prepress \
>    -sDEVICE=pdfwrite -dCompatibilityLevel=2.0 -dNOPAUSE \
>    -dBATCH -o "$PDF_2" "$PDF"

We've recently changed the Producer field for PDF 2.0 and above, in this commit:

f836fe01933038591c4a57c854ef490b4caf93f2

Is it possible for you to test a build of Ghostscript which includes that commit ? Obviously you would have to build Ghostscript from source.

(In reply to Ken Sharp from comment #1)

> Is it possible for you to test a build of Ghostscript which includes that
> commit ? Obviously you would have to build Ghostscript from source.

No I did not. And I want to understand this bug report in the context of a vanilla Linux-installation. I can build Ghostscript from source and give you another feedback.

Currently I am not in the mood to do that. It felt like contributing to the mess. Maybe this XMP rubbish has a use somewhere and maybe I will give you feedback. The world is like that, now.

(In reply to Psycho Chicken from comment #2)


> Currently I am not in the mood to do that. It felt like contributing to the
> mess. Maybe this XMP rubbish has a use somewhere and maybe I will give you
> feedback. The world is like that, now.

The use of XML in PDF is not something we have nay control over, and complaining about it isn't likely to help. Its been made pretty obvious (from recent specifications and drafts) that the intention is to keep on moving towards XML for Metadata, and abandon the PDF-native equivalents. Which is why we do not write the Producer to the Info dictionary in PDF 2.0 or above; its been deprecated.

I don't think its a good idea, but that's not under my control, we just have to live with it.

I did just test the current code with evince, and the old code, and evince does not complain with the output of current Git HEAD. I do see the warnings in the terminal when I use 10.06.0 to create the file.

So I believe this has already been addressed by the commit referenced in comment #1

I have compiled GIT PRERELEASE 10.07.0 (2025-09-09) and find – as expected – that Evince does not longer complain.

cpdf -info <file.pdf> produces:
-----------

Encryption: Not encrypted
Permissions: 
Linearized: false
Object streams: true
ID: <c90a5fb9e610d1f2dc3281862179371c> <c90a5fb9e610d1f2dc3281862179371c>
Version: 2.0
Pages: 7
Title: flnews_post_proc
Author: <michael.uplawski@uplawski.eu>
Subject: 
Keywords: 
Creator: Vim 9.1, Docutils 0.22.4
Producer: FOP 2.11, Ghostscript 10.07.0
Created: D:20260122124502+01'00'
Modified: D:20260122124502+01'00'
Trapped: False
PageMode: UseOutlines
PageLayout: 
OpenAction: 
HideToolbar: 
HideMenubar: 
HideWindowUI: 
FitWindow: 
CenterWindow: 
DisplayDocTitle: 
NonFullScreenPageMode: 
AcroForm: False
XFA: False
Marked: False
UserProperties: False
Suspects: False
MediaBox: 0.000000 0.000000 595.280000 841.890000
CropBox: 0.000000 0.000000 595.275000 841.889000
BleedBox: 0.000000 0.000000 595.275000 841.889000
TrimBox: 0.000000 0.000000 595.275000 841.889000
ArtBox: 
Subformats: 
Language: 
XMP pdf:Producer: GPL Ghostscript GIT PRERELEASE 10.07.0
XMP xmp:CreateDate: 2026-01-22T12:45:02+01:00
XMP xmp:CreatorTool: UnknownApplication
XMP xmp:MetadataDate: 2026-01-22T12:45:02+01:00
XMP xmp:ModifyDate: 2026-01-22T12:45:02+01:00
XMP dc:title: Untitled
----------------
So, you copy the data from the original file into the XMP metadata.

That is okay, although I will develop a routine to do
--------------
      cpdf -set-metadata <(echo "<x:xmpmeta xmlns:x='adobe:ns:meta/' \
        x:xmptk='XMP toolkit 2.9.1-13, framework 1.6'>\
        <!-- This stuff is too ridiculous to be taken seriously.\
        Leave me alone. --></x:xmpmeta>") "$PDF_2" -o "$PDF"
--------------

Resolved Fixed is correct, anyway.

Thank you for the immense work on Ghostscript. Seeing the compiler lines defile is impressive. 

Cheerio.
Ω

(In reply to Psycho Chicken from comment #4)
> I have compiled GIT PRERELEASE 10.07.0 (2025-09-09) and find – as expected –
> that Evince does not longer complain.

Thanks for checking, always worth having a second opinion.


> So, you copy the data from the original file into the XMP metadata.

Mostly... We don't copy the Producer, because Ghostscript is the Producer (it is creating the PDF file) and we don't permit the Producer to be overridden using a pdfmark in the AGPL release.

Other entries in the Document Information dictionary can be replaced using a /DOCINFO pdfmark, which will override the content of the input file, if used correctly.

(In reply to Psycho Chicken from comment #4)
 
> That is okay, although I will develop a routine to do
> --------------
>       cpdf -set-metadata <(echo "<x:xmpmeta xmlns:x='adobe:ns:meta/' \
>         x:xmptk='XMP toolkit 2.9.1-13, framework 1.6'>\
>         <!-- This stuff is too ridiculous to be taken seriously.\
>         Leave me alone. --></x:xmpmeta>") "$PDF_2" -o "$PDF"
> --------------

Or you could, more simply, use -dOmitXMP to tell pdfwrite not to create the XMP metadata in the first place.

See:

https://ghostscript.readthedocs.io/en/latest/VectorDevices.html

and search for OmitXMP. Note that, as the documentation says, some versions of PDF require XMP metadata and this switch will be ignored in those cases.

(In reply to Ken Sharp from comment #6)

> Or you could, more simply, use -dOmitXMP to tell pdfwrite not to create the
> XMP metadata in the first place.
> 
> See:
> 
> https://ghostscript.readthedocs.io/en/latest/VectorDevices.html
> 
> and search for OmitXMP. Note that, as the documentation says, some versions
> of PDF require XMP metadata and this switch will be ignored in those cases.

Indeed. I guess I should do that.
Although – you have understood me – there should be loud protests against how this standard was hammered together from bits and pieces found here and there. No work for the inventor, the mess is for us to sort out. Signed Adobe and all uproar ends.

TY anyway.