Chapter Number Drop-Caps impinges on footnotes (v2.0.4)

[davidc86]

This may not be new, but I'm seeing this now:

I do have my Advanced ptxprint-mods.tex file set to this: % This is the .tex file specific for the SLU project used by PTXprint. % Saved Configuration name: SelaruNewPublication \TOCthreetabfalse \clubpenalty=0 \widowpenalty=0 \NoteCallerSpace=0.0em

So I don't know if the "0" settings for the clubpenalty and widowpenalty is a factor, but I haven't changed these settings in a very long time, and I don't recall seeing this Chapter number issue before.

[mhosken]

Yes that's a bit of a visual pain. It's also a limitation of how we are doing cutouts. I doubt there will be a fix to this soon. So you have 3 lines to push onto the next page or pull 1 line back. If you restore the \widowpenalty, this kind of problem goes away ;). I'll leave the bug open for a bit to see if @davidg-sil feels up to messing with this. But it's really hard to resolve given that where we sort out where chapter numbers go has no idea where on the page the paragraph will end up or whether it gets split, etc.

[davidg-sil]

About the only think I can think of doing is setting \widowpenalty to 10000 temporarily, and then restoring it at the next \everypar. This might actually be possible with something like this (in ptxprint-mods.tex, or whatever its called)

\addtrigger{GEN4.0}{\widowpenalty=10000}
\addtrigger{GEN4.3}{\widowpenalty=100}

Note that you want this in the .tex file, not a trigger file, or the numbers won't be understood as numbers, and you'll need to change GEN to whatever book ID is appropriate. I don't know when widowpenaly gets processed, you probably need to pick a verse in the next paragraph.

[mhosken]

\setcvhook{GEN4.13}{\widowpenalty=1000} or whatever. Just a refresher.

On Tue, 26 Oct 2021, 17:34 davidg-sil, @.***> wrote:

About the only think I can think of doing is setting \widowpenalty to 10000 temporarily, and then restoring it at the next \everypar. This might actually be possible with something like this (in ptxprint-mods.tex, or whatever its called)

\addtrigger{GEN4.0}{\widowpenalty=10000} \addtrigger{GEN4.3}{\widowpenalty=100}

Note that you want this in the .tex file, not a trigger file, or the numbers won't be understood as numbers, and you'll need to change GEN to whatever book ID is appropriate. I don't know when widowpenaly gets processed, you probably need to pick a verse in the next paragraph.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/sillsdev/ptx2pdf/issues/558#issuecomment-951804541, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABLMO3NLML3F2QWPMNJMMSDUI2G4RANCNFSM5GVJRD2Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[davidg-sil]

Yes. I'm not very sure what the difference is between \addtrigger and \addcvhook. Probably none in this situation. \addtrigger can fire in extra places IIRC.

[davidc86]

Hi again, Wow, I'm not following that. I do know that it has improved in my current layout, so the chapter 4 number and all associated lines have moved to the top of the next page. (Fine) But chapter 11 is a bit interesting:

Bottom of page 39:

Top of page 40:

I don't seen any footnote or reference that is forcing the funky indented line onto the next page, and I've set widow so the few words on the last line of that section should be allowed to sit at the top of the page (yeah, ugly, but in principle the settings in PTXprint should have allowed for it). So am I missing something?

Oh, wow, now that I have grid on, I can see that the descenders would cross into the footnote RULE. Is this what is pushing it onto the next page?

(NOTE: turning off % \clubpenalty=0 % \widowpenalty=0 solves the problem, but it might leave other pages a bit wonky.)

So, your call, as to whether it's worth "fixing" when people use flags like these. Or just leave it as "use those flags at your own risk, as other weird things might happen!"

[davidg-sil]

You probably had that on chapter 10, too, before applying the fix. It's made a cut out, and then (because widow lines are allowed) it split the cut-out across the page-break.

The same solution ought to fix it.

[markpenny]

Having just typeset an entire NT in 12 hours, I'm aware that these things can happen; and I'm hoping that you are familiar enough with shrinking/expanding paragraphs in order to suck up an extra line, or grow paragraphs to push these kinds of awkward breaks onto the next page. We have also recently added the ability to "extend" Fonts (as a font feature) which means you can do a horizontal stretch/shrink on the glyphs themselves. This gives the text a bit more stretchability without adding too much white space between words. It is all pretty advanced (targeted at typesetters, not ordinary users), and really needs a training video to show how. My challenge is to work out how to make the power of this kind of flexibility simple enough in the UI so that anyone can make use of it. Still thinking...

[cmahte]

Mark,

I've done preparatory work to eliminate the user on this.... That is, Make the page layout mostly do the typesetting, so that a human doesn't have to go in and tweak it.

The primary target for typsetting is always the same: to have the last page of a block of text (where "block of text here means from a hard page break to the next hard page break) fill between 30-90%, or with shorter blocks, consume at least 4 or 2 lines up to 100% of the last page. There are other lesser problems like spanning footnotes and hyphenated words and orphan/widow paragraphs, but the first problem is not having entirely blank pages with 1 line of text on them where that much break isn't wanted.

And when I'm typesetting here's the formula I follow manually:

Total linelength / (lines in a page * length of each line) = number of pages. But the residual is the concern for the typesetter. If it's 50%, there's no concern, but if there's 90-110% then you want to stretch or squeeze away from the 0% toward 50%. If the remainder is between 25%-75%, then both stretching and squeezing should maintain that midpage ending, but not in close proximity.

There's math to do for whitespace around titles and implied breaks, but it generally works this way. and in manual typesetting I just page forward and look where the last page of the block is, then teypset that block to those parameters... always squeeze, always stretch or maintain neutral space.

On Wed, Oct 27, 2021 at 6:11 PM Mark Penny @.***> wrote:

Having just typeset an entire NT in 12 hours, I'm aware that these things can happen; and I'm hoping that you are familiar enough with shrinking/expanding paragraphs in order to suck up an extra line, or grow paragraphs to push these kinds of awkward breaks onto the next page. We have also recently added the ability to "extend" Fonts (as a font feature) which means you can do a horizontal stretch/shrink on the glyphs themselves. This gives the text a bit more stretchability without adding too much white space between words. It is all pretty advanced (targeted at typesetters, not ordinary users), and really needs a training video to show how. My challenge is to work out how to make the power of this kind of flexibility simple enough in the UI so that anyone can make use of it. Still thinking...

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/sillsdev/ptx2pdf/issues/558#issuecomment-953376031, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC2DE4XKG3LJBBP5633UKMDUJCBKPANCNFSM5GVJRD2Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.