-
Notifications
You must be signed in to change notification settings - Fork 205
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
Add publication/latex/@openodd #2034
Conversation
jjrsylvestre
commented
Aug 3, 2023
- Borrowed from https://tex.stackexchange.com/questions/185821/openright-in-oneside-book
- Hopefully not too hacky.
- Wasn't sure where in the preamble you would want to put it.
- Wasn't sure if different document classes might need to be handled differently, so I just put in the common preamble.
This is a great idea as an option. Two comments:
|
Any time I see `sed`, my hackles get raised. GNU `sed` (Linux and I presume WSL) and BSD `sed` (macOS) have some fundamentally different behaviors that makes using `sed` in an open-source project where folks might be building on different platforms just an absolute nightmare. (We navigated this early on with EPUB.)
`sed` works when it’s basically just the author doing things, but as soon as others get involved, it’s best to find a better method.
… On Aug 3, 2023, at 8:29 AM, kcrisman ***@***.***> wrote:
This is a great idea as an option. Two comments:
Obviously this will have to be in the guide somewhere, preferably multiple places. I expect people will use it, so that pdf and print match page numbers.
Would just changing the document class option be easier/more correct, or worse? It's what I use, in a custom build script I certainly don't mean to imply is "correct PTX" 😄 but which I did for precisely this reason.
sed -i '' 's/documentclass\[oneside/documentclass\[twoside/' foo.tex
—
Reply to this email directly, view it on GitHub <#2034 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACBOYNZMPKY2BF5QICHCYXTXTORSBANCNFSM6AAAAAA3CFXAKA>.
You are receiving this because you are subscribed to this thread.
--
Mitch Keller
***@***.***
http://www.rellek.net/
|
Haha, I didn't mean that PTX should use |
But something like |
Wouldn't |
Well, my very first reaction to your orginal post was going to be "So long as it doesn't include \makeatletter`" ;-) I'll run this through some testing soon. It'll eventually need a very terse entry in the publication file reference chapter, whicvh can point to the "Page Fidelity" section, which I will re-write as part of this. |
Yes! I was confused on which of my changes I was thinking about. My apologies! I was just excited that someone was thinking to implement this. What I use is this solution. But if your option is more robust, it would be great to have it as an official option. |
OK, looking good. Extensive testing with the sample book - no parts, decorative parts, structural parts. Side-by-side comparisons of PDFs indicates complete syncing on page numbers.
Force-push or add a pile-on commit, I can handle either, but please do documentation as a separate commit. Don't merge in master. Thanks very much for doing this - the whole oneside/twoside, left/right, even/odd, recto/verso drill gives me a headache. ;-) |
An idea that came to me while writing documentation (see, there is some value to that act!). What about another option that basically makes The electronic PDF is faithful, but if printed no trees are wasted. A sustainable PDF. |
Will do all of the above.
I actually tried that first, and during my testing xslt gave me an "Unknown error" in the case that the publication file omits the attribute. Didn't want to delve too deep into the |
Note to self: close #1423 when this is done. |
That could possibly be done without When you say "another option" do you mean literally as two different implementations of page-matching (so maybe |
OK, thanks for the explanation. Pinging @Alex-Jordan in case there should be some work to do - it'd be nice to have a more direct formation of that variable. |
Definitely do not want to derail this PR in any way. I was thinking another attribute, but that would be silly. So yes, perhaps a three-way option. |
Do we need value |
I can't completely tell what in the thread is stale. Is To the most recent question, you want a non-empty default value whenever there is a finite list of option values. No publisher file would need to declare |
And then I look and see several such things with no default declared. I think those are about being faithful to the previous scheme, not an intentional choice. I would recommend just always declaring something non-empty for a default, even if it is never explicitly referenced in the XSLT. |
I can't seem to recreate the situation that caused the error message. Must have been some error on my part. But the code that was at issue is not necessary in the new three-option version anyway.
No, changed wholesale from
Sounds good, thanks. |
Thanks very much - I like this a lot. Despite an increase in the use of Some mild repackaging of commits, but no changes in the code. Thanks for a very careful job. I'll button this up and then add some more documentation, as promised. Then rebuild website, etc. |