Ignore Metadata entries with incorrectly encoded characters, when setting the viewer title (bug 1605526) #11423
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…tadata` data With these changes we'll always set the `pdfTitle` to the `Info` dictionary entry *first* (assuming it exists and isn't empty), before attempting to override it with the `Metadata` stream entry (assuming it exists, is non-empty *and* valid). There should be no functional changes with this patch, but it will simplify the following patch somewhat.
Snuffleupagus
commented
Dec 21, 2019
…ting the viewer title (bug 1605526) Apparently Ghostscript can, in some cases, generate/include `Metadata` with incorrectly encoded characters.[1] This results in the viewer title looking wrong, which we thus attempt to avoid by falling back to the `Info` entry instead. *Please note:* Obviously it would be better if this was fixed in the `Metadata` parser instead, rather than using a viewer work-around, but I'm just not sure how or even *if* that could actually be done given that the `Metadata` stream contains no trace of the *original* character. Fixes https://bugzilla.mozilla.org/show_bug.cgi?id=1605526 --- [1] The problematic characters are from the Specials Unicode block, see https://en.wikipedia.org/wiki/Specials_(Unicode_block)
Snuffleupagus
force-pushed
the
bug-1605526
branch
from
18f33f0 to
ad0b0d6
Compare
|
/botio-linux preview |
From: Bot.io (Linux m4)ReceivedCommand cmd_preview from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.67.70.0:8877/a19db83c651bc69/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.67.70.0:8877/a19db83c651bc69/output.txt Total script time: 1.73 mins Published |
timvandermeij
approved these changes
Dec 24, 2019
|
I also looked at the XMP data and couldn't find the original character too, so I think this is the only possible solution here. Thank you for fixing this, and for mentioning the bug IDs for future reference! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Apparently Ghostscript can, in some cases, generate/include
Metadatawith incorrectly encoded characters.[1] This results in the viewer title looking wrong, which we thus attempt to avoid by falling back to theInfoentry instead.Please note: Obviously it would be better if this was fixed in the
Metadataparser instead, rather than using a viewer work-around, but I'm just not sure how or even if that could actually be done given that theMetadatastream contains no trace of the original character.Fixes https://bugzilla.mozilla.org/show_bug.cgi?id=1605526
[1] The problematic characters are from the Specials Unicode block, see https://en.wikipedia.org/wiki/Specials_(Unicode_block)