-
Notifications
You must be signed in to change notification settings - Fork 10.3k
Re-factor the idFactory
functionality, used in the core/
-code, and move the fontID
generation into it
#12070
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…d move the `fontID` generation into it Note how the `getFontID`-method in `src/core/fonts.js` is *completely* global, rather than properly tied to the current document. This means that if you repeatedly open and parse/render, and then close, even the *same* PDF document the `fontID`s will still be incremented continuously. For comparison the `createObjId` method, on `idFactory`, will always create a *consistent* id, assuming of course that the document and its pages are parsed/rendered in the same order. In order to address this inconsistency, it thus seems reasonable to add a new `createFontId` method on the `idFactory` and use that when obtaining `fontID`s. (When the current `getFontID` method was added the `idFactory` didn't actually exist yet, which explains why the code looks the way it does.) *Please note:* Since the document id is (still) part of the `loadedName`, it's thus not possible for different documents to have identical font names.
/botio test |
From: Bot.io (Linux m4)ReceivedCommand cmd_test from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.67.70.0:8877/bce65feb7888441/output.txt |
From: Bot.io (Windows)ReceivedCommand cmd_test from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.215.176.217:8877/ca34ffe211eb1ee/output.txt |
From: Bot.io (Linux m4)FailedFull output at http://54.67.70.0:8877/bce65feb7888441/output.txt Total script time: 26.27 mins
Image differences available at: http://54.67.70.0:8877/bce65feb7888441/reftest-analyzer.html#web=eq.log |
From: Bot.io (Windows)FailedFull output at http://54.215.176.217:8877/ca34ffe211eb1ee/output.txt Total script time: 29.69 mins
Image differences available at: http://54.215.176.217:8877/ca34ffe211eb1ee/reftest-analyzer.html#web=eq.log |
/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/a18851b814d4ed0/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.67.70.0:8877/a18851b814d4ed0/output.txt Total script time: 3.37 mins Published |
Thank you for improving this! |
Note how the
getFontID
-method insrc/core/fonts.js
is completely global, rather than properly tied to the current document. This means that if you repeatedly open and parse/render, and then close, even the same PDF document thefontID
s will still be incremented continuously.For comparison the
createObjId
method, onidFactory
, will always create a consistent id, assuming of course that the document and its pages are parsed/rendered in the same order.In order to address this inconsistency, it thus seems reasonable to add a new
createFontId
method on theidFactory
and use that when obtainingfontID
s. (When the currentgetFontID
method was added theidFactory
didn't actually exist yet, which explains why the code looks the way it does.)Please note: Since the document id is (still) part of the
loadedName
, it's thus not possible for different documents to have identical font names.Implements the idea from #11610 (comment)