-
Notifications
You must be signed in to change notification settings - Fork 98
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
floating marginpar #2068
floating marginpar #2068
Conversation
I've updated this to account for the optional argument to marginpar. If it's present, and Quirks:
The tex code I was using to test this out: \documentclass{article}
\usepackage{latexml}
\newcommand{\sentence}{A long line of text to take up some space.}
\newcommand{\longline}{\sentence\ \sentence\ \sentence\ \sentence\ \sentence\ \sentence}
\begin{lxNavbar}
\lxContextTOC
\end{lxNavbar}
\begin{document}
\reversemarginpar % reversing
\section{Section Title}
A small amount of text.\marginpar{first}\marginpar{second second second second}
\longline\ \longline\ \longline\marginpar{third}\marginpar{fourth}
A small amount of text.
\longline\marginpar[show left]{hide right}
\longline\marginpar{show only on left}
\longline\marginpar[]{hide non empty right}
\normalmarginpar % unreversing
\longline\marginpar{show only on right}
\longline\marginpar[hide left]{show right}
\longline\marginpar[hide non empty left]{}
\section{Section Title}
A section with no margin pars.
\end{document} |
Grr. The real kicker is that I can't commit the actual changes because latexmllint says
but I've not touched State.pm, so I'm not sure why that happened. Any idea what's going on? Any idea how I can fix the git commits to be more reasonable? |
@teepeemm Ah this is unfortunate, this branch has diverged. I generally never use git You can branch off from master and cherry-pick individual commits from here, making a new PR, or use this branch by rewinding back to before your first git merge. (git checkout to the right commit, then a I always do a |
Btw @brucemiller , it looks like latexmllint is indeed failing on the master branch, as Tim reports here. I am not sure how to convince perltidy to recognize constants, currently it complains:
|
As a qucik experiment, I moved the catcode constants to a new say in use base qw(Exporter);
our @EXPORT = (
# Catcode constants
qw( CC_ESCAPE CC_BEGIN CC_END CC_MATH
CC_ALIGN CC_EOL CC_PARAM CC_SUPER
CC_SUB CC_IGNORE CC_SPACE CC_LETTER
CC_OTHER CC_ACTIVE CC_COMMENT CC_INVALID
CC_CS CC_MARKER CC_ARG)
);
use constant CC_ESCAPE => 0;
use constant CC_BEGIN => 1;
use constant CC_END => 2;
use constant CC_MATH => 3;
use constant CC_ALIGN => 4;
use constant CC_EOL => 5;
use constant CC_PARAM => 6;
use constant CC_SUPER => 7;
use constant CC_SUB => 8;
use constant CC_IGNORE => 9;
use constant CC_SPACE => 10;
use constant CC_LETTER => 11;
use constant CC_OTHER => 12;
use constant CC_ACTIVE => 13;
use constant CC_COMMENT => 14;
use constant CC_INVALID => 15;
# Extended Catcodes for expanded output.
use constant CC_CS => 16;
use constant CC_MARKER => 17; # non TeX extension!
use constant CC_ARG => 18; # "out_param" in B Book
|
85a7131
to
937881a
Compare
@dginev I think I managed to resolve the conversations and get the commit history back to looking reasonable, so that this is ready to review and merge. Let me know if I need to do anything else. |
Nice, thank you @teepeemm . Hm, so I made a quick exploration into how the optional argument of \marginpar is used, and I wonder if we aren't creating a mildly misleading feature by respecting it. Generally, latexml does not keep page counts, and does not have a reliable distinction between being on an "even" or "odd" page (unless I am missing something new?). As an example, in the PDF you would expect this simple \marginpar call to use its different arguments on even/odd pages: \documentclass{book}
\def\greeting{\marginpar[even greetings]{odd greetings}}
\begin{document}
\greeting
\clearpage
\greeting
\end{document} I wonder if the Perl binding should only ever use the mandatory (odd page) argument for marginpar, to avoid ever preserving a note expected for the left margin in the XML. What do you think? |
I now also reread the comments, and I understood that you're interested in a left-margin CSS variant, additionally activated via In that case, I may want to deactivate I'm still tempted by the simplicity of ignoring the optional argument and treating all pages as odd for |
Why can't we alternate left and right marginpar reliably? Is there an arXiv document that uses |
We don't even have the concept of pages in HTML, but we kind of do in ePub. Seen differently - say we emit an ePub and show it on a fixed page view of an eink reader. The concrete page numbers will depend on the resolution and size of the display. So a margin note which appears at the top of page
I can try to find one, but the server hosting the documents is down for maintenance this week. Will dig through my local copy... Edit: what the latex docs call "two-sided layout" is generally outside of what we've been working on in our conversions to the web paradigm. |
I don't think we've quite captured the intention of Understanding that, we can now ask how that should be carried over to XML/HTML, where we don't (necessarily) have pages, columns, or even margins --- but we might. The lowest level would be latexml's original behavior to synthesize a marker (dagger) and have the note appear as a popup. The next level would be to build-in a wide margin, either on left or right and place the notes in that margin, without marker, alongside its source (choosing the optional argument as appropriate). The For a truly responsive solution, however, you may have variable margins, may have multiple columns, and you won't know till you detect the device & the user resizes the window. So the XML really should convert & to store both versions of the note, with appropriate attributes/classes, and defer the marker, display & positioning as late as possible to CSS (& javascript if needed). In this scenario the optional argument would be used, but |
I'm not seeing a purely CSS way to determine if a marginpar has appeared in the left or right margin, so I think it would need to involve Javascript for the truly responsive solution. I think this PR does accomplish the "next level" rendering.
|
I'm just not so clear that this is actually an improvement (yet);
The first arg should never appear in the right margin, the 2nd arg should never appear in the left margin. So, I'm thinking if it's worth handling the optional arg at all, we should be storing two notes, with appropriate roles or classes and using CSS; for purpose of argument |
But in html, we don't have pages, so everything acts like page 1, and outside <=> right and inside <=> left. An ePub will have left and right pages, but then we need to figure out if we have a left page or a right page, which doesn't appear to be doable within CSS. Without ePub and some reliable way to determine if it's a left or right page, then we can assume we have a right page. And if we know that we have a right page in the output, then when converting to XML, we know which argument we want to use, and don't need to keep the other. |
That's if you are doing a right-margin CSS design. If you do a left-margin CSS design, everything acts like page 2 :> A problem that hasn't gotten enough attention is legacy authored documents. In arXiv, an author may have known for certain that a specific With that limited application in mind, I'd be happy with a solution that uses arg |
The point is to create a passably nice document by default, while preserving enough information and semantics to give people the flexibility to adapt the styling and layout for whatever medium they're using; webpages, cellphones, epub, etc. So while a default assumption to make the entire document look like a right-hand page is perfectly reasonable, to build in the assumptions that that's the only thing you'll ever be able to do is not ok. Folks ought to be able to easily create a CSS layout with the margin notes on the right or the left. As you point out left notes likely will interfere with a left navbar; so let people choose how it should be laid out. On that basis, I'd be more inclined to think we should ignore In any case, the class While you're probably right that you can't determine whether the note is on the left or right from CSS, you've got the process backwards: it's the CSS that will be applying the styling and layout that makes it be a left or right hand page (eg. unsymmetric margins, or whatever); so the CSS can easily display or hide whichever notes it wants based on the same choices. |
@dginev tells me I wasn't very clear about what I was hoping for; it's pretty simple actually, just awkward to explain. Then, if you want notes in the right margin, you'd use CSS to add some space on the right, and make both The Does that make more sense? |
I really like that proposal actually! |
I think that ends up as one of DefConstructor('\marginpar[]{}',
"?#1(?#2("
."<ltx:note role='margin' class='ltx_marginpar_left'><ltx:inline-para>#1</ltx:inline-para></ltx:note>"
."<ltx:note role='margin' class='ltx_marginpar_right'><ltx:inline-para>#2</ltx:inline-para></ltx:note>)"
."(<ltx:note role='margin' class='ltx_marginpar'><ltx:inline-para>#1</ltx:inline-para></ltx:note>))"
."(<ltx:note role='margin' class='ltx_marginpar'><ltx:inline-para>#2</ltx:inline-para></ltx:note>)");
# or
DefConstructor('\marginpar[]{}', sub {
my ($document, $left, $right) = @_;
if ($left) {
$document->openElement('ltx:note', role => 'margin', 'class' => 'ltx_marginpar' . ($right ? '_left' : ''));
$document->insertElement('ltx:inline-para', $left);
$document->closeElement('ltx:note'); }
if ($right) {
$document->openElement('ltx:note', role => 'margin', 'class' => 'ltx_marginpar' . ($left ? '_right' : ''));
$document->insertElement('ltx:inline-para', $right);
$document->closeElement('ltx:note'); } }); Do you have a preference on which one? I think using the Somewhat related, but I'm having some sort of trouble compiling. No matter what I do to |
I tend to prefer the xml pattern forms, when they're not too complex; plus you probably can assume that there will be an arg 2, so you should be able to use:
make and running latexml normally shouldn't be affected by git; just what's in your working directory; Or the local directory where you're testing from. Maybe there's a stray copy of
|
Oh, if a file has staged changes and local changes, that can make things like |
Ah. I'd copied LaTeX.pool.ltxml into my working directory so that my git fumblings wouldn't overwrite what I was trying to do. Deyan did have a possible example where there would only be the optional argument: if the author was sure that the marginpar was going to be on an even page. So I think we do need to watch out for that possibility. |
Well there has to be the required argument, although it may be empty.
Was the author sure that the marginpar would be on the left? Or were
they saying they didn't want any text, if it appeared on the right? Who
knows; I'd saying such abuses deserve what they get (or don't get :> )
|
Moreover, whatever the author had in mind, the text provided in the optional arg should not be used on the right margin and should still have |
I believe this incorporates everything we've discussed. If there's |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool! I haven't tested it on a real-world example, but the code looks solid.
Nice! I think this will work well by default, as well as with the optional |
This allows marginpars to float (in the CSS sense), so that they display in order instead of overlapping, fixing #2041. LaTeXML-marginpar.css doesn't appear to mesh well with LaTeXML-navbar-left.css (for example
.ltx_page_main { width }
is determined by which is loaded last), so I've not tried to resolve that. On the other hand, if someone is loading both, then they will probably want their own css file anyway.The tex code I was using to test this out: