-
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 paragraph cells in tables #354
Conversation
In order of the diff:
Generally, I think you are working too hard to infer missing widths, which is yielding some overly-complicated XSL and what looks like to me some potential for bugs. Maybe it was my suggestion to condition on "p", but maybe it would be much cleaner to require author to provide a I think I prefer to convert width percentages to reals on the fly in LaTeX (see I can fetch changes as a new commit on this branch if you want to work that way. I don't think Thanks for this - I know how much work this has been. "Believe me." |
OK, I'll work on it and just keep this same branch. Are you intent on capping width at 100%? I can see occasional need to go past that. It would be a big lie anyway because paragraph columns can go alongside non-paragraph columns that have no @width, and just grow to their natural width. And as noted in a thread somewhere earlier today, there is no good way to ascertain their width ahead of time. (How wide is an I'll clean up all the demo formatting from the units table and make a separate torture test table. CDATA cells, line cells, p cells. colspan in the first two types. I think @width as a signal for a paragraph column has problems, because within that column you may want non line breaking cells too. But conditioning on p to make it a paragraph cell and throwing an error if the col has no @width is doable. Is that along the lines you were thinking? I find
I'd prefer to just count cols, and this was in there in case cols had been omitted. But if a @width is required in a col for a paragraph cell, then it becomes a nonissue. Can we really normalize if the table is not necessarily 100% wide? Or maybe you mean normalize when the sum of widths surpasses 100%? Part of the difficulty is still that there can be non-paragraph columns. See comment above about how wide is an I meant Yes, I noticed width-percentage-to-real disappeared when I did a rebase and there was an unusually large conflict I had to address. Quoting you: 'There is a new modal template "width-percent-to-real" that will save you some bother.' Maybe that's when I decided to drop some footnotes in a table ;) |
I just meant if all @width exceeded 100%, then scream. Author makes a typo:
Sure. The automatic widths just seemed too difficult and imperfect, so hitting a
Your call. Style.
Right. If you want to count columns, you need to sum
I just meant
Took me a long time to realize that. Lenz' book is very helpful. Why is the change necessary?
Sorry about that. Code evolves. ;-) Did you plan to provide support for footnotes in tables? If not, they can just go in a paragaph below the table. |
Any thoughts on making the width default to something (say 30%) if it is not specified? In parallel, if there is no width for the col, should this just give a warning, or an error? |
For sidebyside I went 1/N if no widths were given at all. I'd go that far if (a) no @width anywhere (b) and colspan are taken into account to get the correct number of columns. But I think my preference is to just require a @width for any column with a On 08/03/2016 06:37 PM, Alex Jordan wrote:
|
For a paragraph column in a tabular in a sidebyside panel, the @width should On 08/03/2016 06:37 PM, Alex Jordan wrote:
|
David, can you add some css for this? Things needed:
There is a table here where you can see the effect of fiddling with bottom margins: And there is a table here where the next-to-last column has the "justify" class. |
Do I actually have to do this twice? Once for |
Alex, I prefer "j" to "justify". I added CSS for both, and will delete I did paragraph spacing the way I suggested for lists: I made that margin-top be 1em (that is less than 0.9*1.25 but A few issues: The cell: Colspan=2 has "br"s in it, but without the closing slash. I'n not sure why they Other cells with "lines" also have the "br"s, so I am not sure if there is In the paragraph after Table 13.14, the word "Section" is missing before David On Thu, 4 Aug 2016, Alex Jordan wrote:
|
OK, thanks. Looks good. And I have re-written the XSL so that there will not be
I see that but I don't understand why. Here is the XSL that creates those, which is the same structure as how
Should the one line be?
If you only want one line of non-breaking content, with this PR that is accomplished by doing nothing but putting the content into the cell. This will be a change in behavior, but it makes the HTML behavior match the LaTeX behavior. I mentioned this recently in the forum thread. If you use If you take a cell with the "lines" class and make the screen narrow, you will see that there is no breaking between words. For example, at http://spot.pcc.edu/~ajordan/MBX/section-13.html#table-18, the "Lef mid" in the upper left will not break between those words if the screen gets narrow. Arguably you might want it to break, but the point is that the LaTeX would never break in this situation, and authors end up oblivious to the fact that their LaTeX tables are running wide. |
Main existing tabular
Tabular inside sidebyside "panel-box" routines.
Is that sketchy enough? Rob On 08/04/2016 09:29 PM, Alex Jordan wrote:
|
I understand now about the examples you have for "lines".
|
Made another commit. Still no normalization of percentages. And just now realizing still no check that percentages sum to <= 100%. But I think the rest is addressed. Take a look, or wait til I come back to the sum check. David, you can remove the "justify" class. It's using "j" now. |
Done
|
Apparently not closing br is proper HMTL. Same for link, img, and meta judging by some tags in MBX HMTL output that are not being closed by XSLT. http://stackoverflow.com/questions/3558119/are-self-closing-tags-valid-in-html5 |
My reading of that answer is that closing the br tag is also valid, Since Firefox (on my computer) supplies the closing tag, my suggestion is On Mon, 8 Aug 2016, Alex Jordan wrote:
|
I do not think we can make the closing tag without circumventing clean xsl. We are using method="html" for the HTML output, and xsltproc apparently <xsl:element name="br" /> <xsl:element name="br">/xsl:element xsltproc processes these html elements this way when method="html". With method="xml", you get closing tags. But I saw directly this is really The only thing I can think if is literally writing them out with <xsl:text disable-output-escaping="yes"><br />/xsl:text It seems like a red flag to have to do this though. And the answer at that On Mon, Aug 8, 2016 at 5:02 PM, davidfarmer notifications@github.com
Alex Jordan |
OK Rob, ready for you to take a look. My XSL is getting better. |
Thanks, Alex. May peek soon, but at AIM right now, so may not get totally Yes, your XSL has been improving rapidly for a quite some time. Get a copy of Rob On 08/09/2016 06:24 PM, Alex Jordan wrote:
|
I think this is ready to go. One suggestion, one question. I'm happy to make changes as part of merging this - just let me know what you think. In the maximum-width routine, I think <xsl:if test="count($nodeset) > 0"> can become just <xsl:if test="$nodeset"> Two places, close by each other, you have: match="mathbook//tabular"
match="mathbook//row" What is the purpose of the |
If you think As for At some phase of testing, widths just were not being passed down, even though by rights, it appeared to me that they should have. Some forum post somewhere suggested adding the root ancestor to the match. I did, and it worked. (I should have commented the details; live and learn.) I guess we could remove the
|
OK, after a good night's sleep, let me walk back some of my "nearly certain"ness. Ultimately we required the author to give width for a paragraph column. But there was a time when the author could give no width, and I was having it deduce the width by counting cols in the tabular. Or, if there were no cols, by counting cells in a row. There was a template in mathbook-common that did this. And I think this is the thing I couldn't get to work until I added In short I think you can take those |
Sleep is good. ;-) Lenz says: "a node-set converts to false if the node-set is empty, true otherwise." I'll simplify. Well, that all sounds highly suspect to me. There's a lot of crazy XSL suggestions out there from folks who clearly don't know what they are doing. I've learned the hard way. ;-) I'm not even sure you are at the root, that'd mean writing |
Behaving quite well with discussed changes. Working great, in fact. One more cruise before I clean-up and merge. Would you like the honors to announce, once I'm done? That's an invitation, not a request. ;-) |
Please go ahead and announce. Only having spotty time to be online today. Thanks for reviewing and testing! Pretty sure the quirk I ran into was with On Sun, Sep 25, 2016 at 12:40 PM, Rob Beezer notifications@github.com
Alex Jordan |
Merged with two changes discussed above simply added into the one commit. Thanks very much for this! (And your patience!) |
Here it is for LaTeX and HTML. (Upon reflection today, I don't think it's necessary to pursue this with PG. All cells in WeBWorK tables are paragraph-cells anyway.)
As this is right now, there needs to be a CSS class "justify" with
text:align:justify;
. David, please add that if this PR is approved.Comments and alteration requests welcome. My git fu (jugitsu?) can handle changes easily enough now.