prevent xelatex from compressing the output
In a huge book I edit, I sometimes simplify (beautify, or change in some other way) the global macros defined in the preamble via def or (new|renew|provide)command and then observe whether the change had any effect on the compilation time and on the output PDF file. For this purpose, I measure the times for compiling the book via usrbintime -p <my compilation command> and compare the file before the changes with the file after the changes with diff -a book_before_the_changes.pdf book_after_the_changes.pdf. When the macro simplification had no effect, the only change diff spits out is a human-readable ACSII timestamp, which I can read off the screen. When the macro simplification did have some effect, diff spits out a bunch of unreadable gibberish, which leads me to examine the situation further by a command such as diffpdf, which takes way, way longer.
Recently, I switched from pdflatex to xelatex, which compresses the output PDF files in such a way that diff -a book_before_the_changes.pdf book_after_the_changes.pdf ALWAYS outputs unreadable gibberish. Is there a way to handle this problem, e.g., by preventing the compression, or by quickly comparing the previous and the current version for meaningful changes via some other utility? If there is such a way, what would it be?
xetex
asked 11 hours ago
user49915user49915
736122
add a comment |
In a huge book I edit, I sometimes simplify (beautify, or change in some other way) the global macros defined in the preamble via def or (new|renew|provide)command and then observe whether the change had any effect on the compilation time and on the output PDF file. For this purpose, I measure the times for compiling the book via usrbintime -p <my compilation command> and compare the file before the changes with the file after the changes with diff -a book_before_the_changes.pdf book_after_the_changes.pdf. When the macro simplification had no effect, the only change diff spits out is a human-readable ACSII timestamp, which I can read off the screen. When the macro simplification did have some effect, diff spits out a bunch of unreadable gibberish, which leads me to examine the situation further by a command such as diffpdf, which takes way, way longer.
Recently, I switched from pdflatex to xelatex, which compresses the output PDF files in such a way that diff -a book_before_the_changes.pdf book_after_the_changes.pdf ALWAYS outputs unreadable gibberish. Is there a way to handle this problem, e.g., by preventing the compression, or by quickly comparing the previous and the current version for meaningful changes via some other utility? If there is such a way, what would it be?
xetex
asked 11 hours ago
user49915user49915
736122
Ulrike has given a suggestion of z0 whilst you may use a slightly higher number and general advise is use z9 for final however I would look at z7 and z8 decompess times to ensure an end user is not put off by the viewer decompression times see tex.stackexchange.com/a/263695/170109
– KJO
11 hours ago
@KJO I need zero, absolutely no compression in the output. As for the times, I have different experience than you. As for by testbed, it's 25.16 s by default and 25.43 s without any compression as Ulrike suggested. So, 1% of difference – not that of a big deal.
– user49915
10 hours ago
I understood need/desire for zero but some diff(ers) can do some levels of decompress prior to shifting for visual comparison, thus "may" depending on your tool-set, main suggestion was consider joe public when publishing
– KJO
10 hours ago
@KJO It'sdiff (GNU diffutils) 3.6.
– user49915
10 hours ago
agreed no decompress options in diffutils
– KJO
10 hours ago
add a comment |
In a huge book I edit, I sometimes simplify (beautify, or change in some other way) the global macros defined in the preamble via def or (new|renew|provide)command and then observe whether the change had any effect on the compilation time and on the output PDF file. For this purpose, I measure the times for compiling the book via usrbintime -p <my compilation command> and compare the file before the changes with the file after the changes with diff -a book_before_the_changes.pdf book_after_the_changes.pdf. When the macro simplification had no effect, the only change diff spits out is a human-readable ACSII timestamp, which I can read off the screen. When the macro simplification did have some effect, diff spits out a bunch of unreadable gibberish, which leads me to examine the situation further by a command such as diffpdf, which takes way, way longer.
Recently, I switched from pdflatex to xelatex, which compresses the output PDF files in such a way that diff -a book_before_the_changes.pdf book_after_the_changes.pdf ALWAYS outputs unreadable gibberish. Is there a way to handle this problem, e.g., by preventing the compression, or by quickly comparing the previous and the current version for meaningful changes via some other utility? If there is such a way, what would it be?
xetex
asked 11 hours ago
user49915user49915
736122
In a huge book I edit, I sometimes simplify (beautify, or change in some other way) the global macros defined in the preamble via def or (new|renew|provide)command and then observe whether the change had any effect on the compilation time and on the output PDF file. For this purpose, I measure the times for compiling the book via usrbintime -p <my compilation command> and compare the file before the changes with the file after the changes with diff -a book_before_the_changes.pdf book_after_the_changes.pdf. When the macro simplification had no effect, the only change diff spits out is a human-readable ACSII timestamp, which I can read off the screen. When the macro simplification did have some effect, diff spits out a bunch of unreadable gibberish, which leads me to examine the situation further by a command such as diffpdf, which takes way, way longer.
Recently, I switched from pdflatex to xelatex, which compresses the output PDF files in such a way that diff -a book_before_the_changes.pdf book_after_the_changes.pdf ALWAYS outputs unreadable gibberish. Is there a way to handle this problem, e.g., by preventing the compression, or by quickly comparing the previous and the current version for meaningful changes via some other utility? If there is such a way, what would it be?
xetex
xetex
asked 11 hours ago
user49915user49915
736122
asked 11 hours ago
user49915user49915
736122
edited 11 hours ago
user49915
asked 11 hours ago
user49915user49915
736122
asked 11 hours ago
user49915user49915
736122
asked 11 hours ago
user49915user49915
736122
736122
Ulrike has given a suggestion of z0 whilst you may use a slightly higher number and general advise is use z9 for final however I would look at z7 and z8 decompess times to ensure an end user is not put off by the viewer decompression times see tex.stackexchange.com/a/263695/170109
– KJO
11 hours ago
@KJO I need zero, absolutely no compression in the output. As for the times, I have different experience than you. As for by testbed, it's 25.16 s by default and 25.43 s without any compression as Ulrike suggested. So, 1% of difference – not that of a big deal.
– user49915
10 hours ago
I understood need/desire for zero but some diff(ers) can do some levels of decompress prior to shifting for visual comparison, thus "may" depending on your tool-set, main suggestion was consider joe public when publishing
– KJO
10 hours ago
@KJO It'sdiff (GNU diffutils) 3.6.
– user49915
10 hours ago
agreed no decompress options in diffutils
– KJO
10 hours ago
add a comment |
Ulrike has given a suggestion of z0 whilst you may use a slightly higher number and general advise is use z9 for final however I would look at z7 and z8 decompess times to ensure an end user is not put off by the viewer decompression times see tex.stackexchange.com/a/263695/170109
– KJO
11 hours ago
@KJO I need zero, absolutely no compression in the output. As for the times, I have different experience than you. As for by testbed, it's 25.16 s by default and 25.43 s without any compression as Ulrike suggested. So, 1% of difference – not that of a big deal.
– user49915
10 hours ago
I understood need/desire for zero but some diff(ers) can do some levels of decompress prior to shifting for visual comparison, thus "may" depending on your tool-set, main suggestion was consider joe public when publishing
– KJO
10 hours ago
@KJO It'sdiff (GNU diffutils) 3.6.
– user49915
10 hours ago
agreed no decompress options in diffutils
– KJO
10 hours ago
Ulrike has given a suggestion of z0 whilst you may use a slightly higher number and general advise is use z9 for final however I would look at z7 and z8 decompess times to ensure an end user is not put off by the viewer decompression times see tex.stackexchange.com/a/263695/170109
– KJO
11 hours ago
Ulrike has given a suggestion of z0 whilst you may use a slightly higher number and general advise is use z9 for final however I would look at z7 and z8 decompess times to ensure an end user is not put off by the viewer decompression times see tex.stackexchange.com/a/263695/170109
– KJO
11 hours ago
@KJO I need zero, absolutely no compression in the output. As for the times, I have different experience than you. As for by testbed, it's 25.16 s by default and 25.43 s without any compression as Ulrike suggested. So, 1% of difference – not that of a big deal.
– user49915
10 hours ago
@KJO I need zero, absolutely no compression in the output. As for the times, I have different experience than you. As for by testbed, it's 25.16 s by default and 25.43 s without any compression as Ulrike suggested. So, 1% of difference – not that of a big deal.
– user49915
10 hours ago
I understood need/desire for zero but some diff(ers) can do some levels of decompress prior to shifting for visual comparison, thus "may" depending on your tool-set, main suggestion was consider joe public when publishing
– KJO
10 hours ago
I understood need/desire for zero but some diff(ers) can do some levels of decompress prior to shifting for visual comparison, thus "may" depending on your tool-set, main suggestion was consider joe public when publishing
– KJO
10 hours ago
@KJO It's
diff (GNU diffutils) 3.6.– user49915
10 hours ago
@KJO It's
diff (GNU diffutils) 3.6.– user49915
10 hours ago
agreed no decompress options in diffutils
– KJO
10 hours ago
agreed no decompress options in diffutils
– KJO
10 hours ago
add a comment |
1 Answer
1
active
oldest
votes
You can avoid the compression with a special:
documentclass{article}
special{dvipdfmx:config z 0}
begin{document}
blbl
end{document}
The l3build testing system can also make test based on the pdf-output -- it creates file where binaries and other stuff that changes during compilation (like dates) are removed.
answered 11 hours ago
Ulrike FischerUlrike Fischer
198k9305692
First and foremost, thank you. Second, usingspecial{dvipdfmx:config z 0}I do get (mostly) human-readable ASCII text, but I get a little bit too much. E.g., I get pages of differences due to the randomization of the identifiers of the used fonts, for example. (Moreover, omitting compression consumes 1% more of real time, but I guess I can tolerate that.) So, should I go forl3build? Which portion of the documentationtexdoc l3buildwould be applicable? (I'm a bit lost there.)
– user49915
10 hours ago
Well I do my testing with l3build, but it is mostly luatex related, I can't say how well it works with xelatex, and I can't say it if is useful for your usecase.
– Ulrike Fischer
10 hours ago
I see. Is it possible to set the randomization seed in advance so that font identifiers will be deterministic?
– user49915
10 hours ago
2
Alsoxelatex -output-driver="xdvipdfmx -z 0"can be used. I'm not sure it's possible to act also on object streams.
– egreg
10 hours ago
1
Regarding the font name set the environment variables as describe here (with my comment) tex.stackexchange.com/a/391541/2388
– Ulrike Fischer
10 hours ago
|
show 3 more comments
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "85"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f483038%2fprevent-xelatex-from-compressing-the-output%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
You can avoid the compression with a special:
documentclass{article}
special{dvipdfmx:config z 0}
begin{document}
blbl
end{document}
The l3build testing system can also make test based on the pdf-output -- it creates file where binaries and other stuff that changes during compilation (like dates) are removed.
answered 11 hours ago
Ulrike FischerUlrike Fischer
198k9305692
First and foremost, thank you. Second, usingspecial{dvipdfmx:config z 0}I do get (mostly) human-readable ASCII text, but I get a little bit too much. E.g., I get pages of differences due to the randomization of the identifiers of the used fonts, for example. (Moreover, omitting compression consumes 1% more of real time, but I guess I can tolerate that.) So, should I go forl3build? Which portion of the documentationtexdoc l3buildwould be applicable? (I'm a bit lost there.)
– user49915
10 hours ago
Well I do my testing with l3build, but it is mostly luatex related, I can't say how well it works with xelatex, and I can't say it if is useful for your usecase.
– Ulrike Fischer
10 hours ago
I see. Is it possible to set the randomization seed in advance so that font identifiers will be deterministic?
– user49915
10 hours ago
2
Alsoxelatex -output-driver="xdvipdfmx -z 0"can be used. I'm not sure it's possible to act also on object streams.
– egreg
10 hours ago
1
Regarding the font name set the environment variables as describe here (with my comment) tex.stackexchange.com/a/391541/2388
– Ulrike Fischer
10 hours ago
|
show 3 more comments
You can avoid the compression with a special:
documentclass{article}
special{dvipdfmx:config z 0}
begin{document}
blbl
end{document}
The l3build testing system can also make test based on the pdf-output -- it creates file where binaries and other stuff that changes during compilation (like dates) are removed.
answered 11 hours ago
Ulrike FischerUlrike Fischer
198k9305692
First and foremost, thank you. Second, usingspecial{dvipdfmx:config z 0}I do get (mostly) human-readable ASCII text, but I get a little bit too much. E.g., I get pages of differences due to the randomization of the identifiers of the used fonts, for example. (Moreover, omitting compression consumes 1% more of real time, but I guess I can tolerate that.) So, should I go forl3build? Which portion of the documentationtexdoc l3buildwould be applicable? (I'm a bit lost there.)
– user49915
10 hours ago
Well I do my testing with l3build, but it is mostly luatex related, I can't say how well it works with xelatex, and I can't say it if is useful for your usecase.
– Ulrike Fischer
10 hours ago
I see. Is it possible to set the randomization seed in advance so that font identifiers will be deterministic?
– user49915
10 hours ago
2
Alsoxelatex -output-driver="xdvipdfmx -z 0"can be used. I'm not sure it's possible to act also on object streams.
– egreg
10 hours ago
1
Regarding the font name set the environment variables as describe here (with my comment) tex.stackexchange.com/a/391541/2388
– Ulrike Fischer
10 hours ago
|
show 3 more comments
You can avoid the compression with a special:
documentclass{article}
special{dvipdfmx:config z 0}
begin{document}
blbl
end{document}
The l3build testing system can also make test based on the pdf-output -- it creates file where binaries and other stuff that changes during compilation (like dates) are removed.
answered 11 hours ago
Ulrike FischerUlrike Fischer
198k9305692
You can avoid the compression with a special:
documentclass{article}
special{dvipdfmx:config z 0}
begin{document}
blbl
end{document}
The l3build testing system can also make test based on the pdf-output -- it creates file where binaries and other stuff that changes during compilation (like dates) are removed.
answered 11 hours ago
Ulrike FischerUlrike Fischer
198k9305692
answered 11 hours ago
Ulrike FischerUlrike Fischer
198k9305692
answered 11 hours ago
Ulrike FischerUlrike Fischer
198k9305692
answered 11 hours ago
Ulrike FischerUlrike Fischer
198k9305692
198k9305692
First and foremost, thank you. Second, usingspecial{dvipdfmx:config z 0}I do get (mostly) human-readable ASCII text, but I get a little bit too much. E.g., I get pages of differences due to the randomization of the identifiers of the used fonts, for example. (Moreover, omitting compression consumes 1% more of real time, but I guess I can tolerate that.) So, should I go forl3build? Which portion of the documentationtexdoc l3buildwould be applicable? (I'm a bit lost there.)
– user49915
10 hours ago
Well I do my testing with l3build, but it is mostly luatex related, I can't say how well it works with xelatex, and I can't say it if is useful for your usecase.
– Ulrike Fischer
10 hours ago
I see. Is it possible to set the randomization seed in advance so that font identifiers will be deterministic?
– user49915
10 hours ago
2
Alsoxelatex -output-driver="xdvipdfmx -z 0"can be used. I'm not sure it's possible to act also on object streams.
– egreg
10 hours ago
1
Regarding the font name set the environment variables as describe here (with my comment) tex.stackexchange.com/a/391541/2388
– Ulrike Fischer
10 hours ago
|
show 3 more comments
First and foremost, thank you. Second, usingspecial{dvipdfmx:config z 0}I do get (mostly) human-readable ASCII text, but I get a little bit too much. E.g., I get pages of differences due to the randomization of the identifiers of the used fonts, for example. (Moreover, omitting compression consumes 1% more of real time, but I guess I can tolerate that.) So, should I go forl3build? Which portion of the documentationtexdoc l3buildwould be applicable? (I'm a bit lost there.)
– user49915
10 hours ago
Well I do my testing with l3build, but it is mostly luatex related, I can't say how well it works with xelatex, and I can't say it if is useful for your usecase.
– Ulrike Fischer
10 hours ago
I see. Is it possible to set the randomization seed in advance so that font identifiers will be deterministic?
– user49915
10 hours ago
2
Alsoxelatex -output-driver="xdvipdfmx -z 0"can be used. I'm not sure it's possible to act also on object streams.
– egreg
10 hours ago
1
Regarding the font name set the environment variables as describe here (with my comment) tex.stackexchange.com/a/391541/2388
– Ulrike Fischer
10 hours ago
First and foremost, thank you. Second, using
special{dvipdfmx:config z 0} I do get (mostly) human-readable ASCII text, but I get a little bit too much. E.g., I get pages of differences due to the randomization of the identifiers of the used fonts, for example. (Moreover, omitting compression consumes 1% more of real time, but I guess I can tolerate that.) So, should I go for l3build? Which portion of the documentation texdoc l3build would be applicable? (I'm a bit lost there.)– user49915
10 hours ago
First and foremost, thank you. Second, using
special{dvipdfmx:config z 0} I do get (mostly) human-readable ASCII text, but I get a little bit too much. E.g., I get pages of differences due to the randomization of the identifiers of the used fonts, for example. (Moreover, omitting compression consumes 1% more of real time, but I guess I can tolerate that.) So, should I go for l3build? Which portion of the documentation texdoc l3build would be applicable? (I'm a bit lost there.)– user49915
10 hours ago
Well I do my testing with l3build, but it is mostly luatex related, I can't say how well it works with xelatex, and I can't say it if is useful for your usecase.
– Ulrike Fischer
10 hours ago
Well I do my testing with l3build, but it is mostly luatex related, I can't say how well it works with xelatex, and I can't say it if is useful for your usecase.
– Ulrike Fischer
10 hours ago
I see. Is it possible to set the randomization seed in advance so that font identifiers will be deterministic?
– user49915
10 hours ago
I see. Is it possible to set the randomization seed in advance so that font identifiers will be deterministic?
– user49915
10 hours ago
2
2
Also
xelatex -output-driver="xdvipdfmx -z 0" can be used. I'm not sure it's possible to act also on object streams.– egreg
10 hours ago
Also
xelatex -output-driver="xdvipdfmx -z 0" can be used. I'm not sure it's possible to act also on object streams.– egreg
10 hours ago
1
1
Regarding the font name set the environment variables as describe here (with my comment) tex.stackexchange.com/a/391541/2388
– Ulrike Fischer
10 hours ago
Regarding the font name set the environment variables as describe here (with my comment) tex.stackexchange.com/a/391541/2388
– Ulrike Fischer
10 hours ago
|
show 3 more comments
Thanks for contributing an answer to TeX - LaTeX Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f483038%2fprevent-xelatex-from-compressing-the-output%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Ulrike has given a suggestion of z0 whilst you may use a slightly higher number and general advise is use z9 for final however I would look at z7 and z8 decompess times to ensure an end user is not put off by the viewer decompression times see tex.stackexchange.com/a/263695/170109
– KJO
11 hours ago
@KJO I need zero, absolutely no compression in the output. As for the times, I have different experience than you. As for by testbed, it's 25.16 s by default and 25.43 s without any compression as Ulrike suggested. So, 1% of difference – not that of a big deal.
– user49915
10 hours ago
I understood need/desire for zero but some diff(ers) can do some levels of decompress prior to shifting for visual comparison, thus "may" depending on your tool-set, main suggestion was consider joe public when publishing
– KJO
10 hours ago
@KJO It's
diff (GNU diffutils) 3.6.– user49915
10 hours ago
agreed no decompress options in diffutils
– KJO
10 hours ago