keeping in sync with pdftex changes
pdftex will in texlive 2021 change in two places 1. links where \pdfstartlink is in a different boxing level as \pdfendlink are no longer a fatal error but gives only a warning: x\hbox{\pdfstartlink attr {/Border[0 0 1]} user{ /Subtype/Link% /A<<% /Type/Action% /S/URI% /URI(blkub)% >>% } Linktext} \pdfendlink \bye pdfTeX warning: \pdfendlink ended up in different nesting level than \pdfstartl ink 2. There are two new primitives \pdfrunninglinkoff & \pdfrunninglinkon which allow to interrupt a running link for example in the header or footer. Would it be possible to get this changes into luatex too? -- Ulrike Fischer http://www.troubleshooting-tex.de/
Nice to hear that pdftex |is not frozen totally. Could you please implement \localleftbox| and |\localrightbox macros from luatex (or Omega) to pdftex?| These are very useful macros for example I use it for links break in DVI mode. Where I close the active link on the line break and reopen it on the next line. And this perfectly works in page breaks, footnotes, floats Thanks, Linas On 1/11/2021 1:51 PM, Ulrike Fischer wrote:
pdftex will in texlive 2021 change in two places
1. links where \pdfstartlink is in a different boxing level as \pdfendlink are no longer a fatal error but gives only a warning:
x\hbox{\pdfstartlink attr {/Border[0 0 1]} user{ /Subtype/Link% /A<<% /Type/Action% /S/URI% /URI(blkub)% >>% } Linktext} \pdfendlink
\bye
pdfTeX warning: \pdfendlink ended up in different nesting level than \pdfstartl ink
2. There are two new primitives \pdfrunninglinkoff & \pdfrunninglinkon which allow to interrupt a running link for example in the header or footer.
Would it be possible to get this changes into luatex too?
On 1/11/2021 3:34 PM, Linas Stonys wrote:
Nice to hear that pdftex |is not frozen totally. Could you please implement \localleftbox| and |\localrightbox macros from luatex (or Omega) to pdftex?| These are very useful macros for example I use it for links break in DVI mode. Where I close the active link on the line break and reopen it on the next line. And this perfectly works in page breaks, footnotes, floats These are primitives, not macros, and being primitives they depend on core engine functionality. Now, I'm not sure to what extend pdftex is extended in fundamental ways but these local boxes are more substantial:
- they demand whatsit nodes that register these boxes (as they can change any time) - they use some non-standard list management (as they can be used multiple times) - they also result in an adaptation of the (post) line break routines So, it probably makes more sense to use luatex in dvi mode. Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
Am Mon, 11 Jan 2021 16:34:48 +0200 schrieb Linas Stonys:
Nice to hear that pdftex |is not frozen totally. Could you please implement \localleftbox| and |\localrightbox macros from luatex (or Omega) to pdftex?|
I'm not involved in pdftex development. The changes I mentioned where added by Hàn Thế Thành last year because I asked for them some time ago on the texlive list. -- Ulrike Fischer http://www.troubleshooting-tex.de/
On 1/11/2021 12:51 PM, Ulrike Fischer wrote:
pdftex will in texlive 2021 change in two places
1. links where \pdfstartlink is in a different boxing level as \pdfendlink are no longer a fatal error but gives only a warning:
x\hbox{\pdfstartlink attr {/Border[0 0 1]} user{ /Subtype/Link% /A<<% /Type/Action% /S/URI% /URI(blkub)% >>% } Linktext} \pdfendlink
\bye
pdfTeX warning: \pdfendlink ended up in different nesting level than \pdfstartl ink
2. There are two new primitives \pdfrunninglinkoff & \pdfrunninglinkon which allow to interrupt a running link for example in the header or footer.
Would it be possible to get this changes into luatex too? I assume that is just a 'disable' / 'enable' option registered in some whatsit, i.e. no fancy split into multiple links case and no keeping
hm, so bad nesting is not an error ... anyway ./pdf/pdflink.c 75: normal_error("pdf backend","'endlink' ended up in vlist"); ./pdf/pdflink.c 79: normal_error("pdf backend","'endlink' ended up in different nesting level than 'startlink'"); ./pdf/pdfthread.c 111: normal_error("pdf backend", "'endthread' ended up in hlist"); ./pdf/pdfthread.c 113: normal_error("pdf backend", "'endthread' ended up in different nesting level than 'startthread'"); If we do that then threads also get a warning instead of an error and we also won't be picky on a mode change. (So four cases where an error becomes a warning.) track of nested on/off states? (So just some quick and dirty on/off handling). Again also for threads I guess. Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
On Mon, Jan 11, 2021 at 3:43 PM Hans Hagen
On 1/11/2021 12:51 PM, Ulrike Fischer wrote:
pdftex will in texlive 2021 change in two places
1. links where \pdfstartlink is in a different boxing level as \pdfendlink are no longer a fatal error but gives only a warning:
x\hbox{\pdfstartlink attr {/Border[0 0 1]} user{ /Subtype/Link% /A<<% /Type/Action% /S/URI% /URI(blkub)% >>% } Linktext} \pdfendlink
\bye
pdfTeX warning: \pdfendlink ended up in different nesting level than \pdfstartl ink
hm, so bad nesting is not an error ... anyway
./pdf/pdflink.c 75: normal_error("pdf backend","'endlink' ended up in vlist"); ./pdf/pdflink.c 79: normal_error("pdf backend","'endlink' ended up in different nesting level than 'startlink'"); ./pdf/pdfthread.c 111: normal_error("pdf backend", "'endthread' ended up in hlist"); ./pdf/pdfthread.c 113: normal_error("pdf backend", "'endthread' ended up in different nesting level than 'startthread'");
If we do that then threads also get a warning instead of an error and we also won't be picky on a mode change. (So four cases where an error becomes a warning.)
hm. Couldn't be an option at format level ? I don't like the idea that something wrong now suddenly becomes right --- unless it was an error to mark it as wrong from the beginning. -- luigi
Am Mon, 11 Jan 2021 16:01:09 +0100 schrieb luigi scarso:
I don't like the idea that something wrong now suddenly becomes right ---
Well I never understood why this is a fatal error. Why does pdftex or luatex care in my example about the boxing level? The worst that can happen is that pdftex calculates a wrong link area, so a warning makes sense. But the pdf is valid and there is imho (like with duplicated or missing destination names) no real reason to stop alltogether. -- Ulrike Fischer http://www.troubleshooting-tex.de/
On 1/11/2021 4:15 PM, Ulrike Fischer wrote:
Am Mon, 11 Jan 2021 16:01:09 +0100 schrieb luigi scarso:
I don't like the idea that something wrong now suddenly becomes right ---
Well I never understood why this is a fatal error. Why does pdftex or luatex care in my example about the boxing level? The worst that can happen is that pdftex calculates a wrong link area, so a warning makes sense. But the pdf is valid and there is imho (like with duplicated or missing destination names) no real reason to stop alltogether. If that is the new criterium for error or no error, then what about
invalid node of type ... in discretionary (where the machinery can just ignore that node) Other examples are: tex doesn't always error on overflow (dimensions can cycle) so why not silently recover in all cases. And do we really care if a file ends inside an if? Or why make "a non-empty hbox expected" in margin kerns an error? Actually it makes sense to just ignore unknown parameters (keys) to some pdf related commands (probabbly less conceptual tricky than ignoring bad nesting). Errors in virtual fonts also are candidates. Invalid major or minor versions can be warnings instead of errors and invalid steps in expansion can be clipped to sensible values as can stack over- and underflow. Where does it end (in an engine that is supposed to be stable). One can argue that it's up to the programmer (Knuth for the core engine, Thanh for pdftex extensions) which is quite valid but then we also must stress that luatex isn't compatible with pdftex in all aspects. So, I agree with Luigi that it is kind of dubious (unless we make most non fatal looking backend errors optional i.e. turn them warning when some flag is set). The tex core has sometimes 'recovery' warnings (after error help) but that's too much work (and still it would be an error). Anyway, we will ponder it. Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
Am Mon, 11 Jan 2021 17:09:38 +0100 schrieb Hans Hagen:
I don't like the idea that something wrong now suddenly becomes right ---
Well I never understood why this is a fatal error. Why does pdftex or luatex care in my example about the boxing level? The worst that can happen is that pdftex calculates a wrong link area, so a warning makes sense. But the pdf is valid and there is imho (like with duplicated or missing destination names) no real reason to stop alltogether.
If that is the new criterium for error or no error,
Why new? There are already a number of "errors" which only give warnings or info, e.g. destination with the same identifier ... or (\end occurred inside a group at level 1) or from the user view actually often quite problematic the Missing Character message. So you always have to consider if you think an error is fatal or not. And in the case of links it is actually quite unclear why it should be an error at all. There is nothing logically wrong with the idea to have the "stop" marker in some other box level. dvipdfmx doesn't give a fatal error either: it uses the box level to decide if something is part of the link or not, but the eann special can be in any level: x\hbox{\special{pdf:bann <>>>} linked} not linked \hbox{more linktext} not linked \special{pdf:eann} \hbox{not linked anymore} \bye (It is not an very important change. The one case in LaTeX where it really mattered has been resolve by adjusting the box levels. I only mentioned it here too, so that you can consider it. The ability to stop a running link is much more needed.) -- Ulrike Fischer https://www.troubleshooting-tex.de/
On 1/11/2021 6:12 PM, Ulrike Fischer wrote:
(It is not an very important change. The one case in LaTeX where it really mattered has been resolve by adjusting the box levels. I only mentioned it here too, so that you can consider it. The ability to stop a running link is much more needed.) After updating pdftex i tested that feature (somewhat stupid example as we don't use this link command in context):
\pdfobjcompresslevel0 \pdfcompresslevel0 \starttext test [\pdfrunninglinkoff [\pdfstartlink goto page 2 {}whatever page 1\pdfendlink]% \pdfrunninglinkon] test \vskip1cm \pdfrunninglinkoff [\pdfstartlink goto page 2 {}whatever page 2\pdfendlink]% \pdfrunninglinkon \vskip1cm [\pdfstartlink goto page 2 {}whatever \pdfrunninglinkoff page\pdfrunninglinkon 3\pdfendlink]% \vskip1cm [\pdfstartlink goto page 2 {}whatever before \pdfrunninglinkoff page \pdfrunninglinkon after whatever \pdfendlink] \vskip1cm [\pdfstartlink goto page 2 {}whatever \pdfrunninglinkoff page \pdfrunninglinkon whatever \pdfendlink] \vskip1cm [\pdfstartlink goto page 2 {}whatever yes \pdfrunninglinkoff page \vadjust{also no} \vadjust pre {also yes} page \par no \pdfrunninglinkon whatever \pdfendlink] \page here \stoptext so, this flag is somewhat unpredictable in the sense that it influences the next box at the upper level and has no effect in the middle or preceding (either or not migrated) boxes inside the setting. I looked at the pdftex source and it's not hard to implement (which also explains the above behavioir) and we don't need to document it. Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
Am Mon, 11 Jan 2021 19:11:16 +0100 schrieb Hans Hagen:
After updating pdftex i tested that feature (somewhat stupid example as we don't use this link command in context):
How do you make breakable links then?
so, this flag is somewhat unpredictable in the sense that it influences the next box at the upper level and has no effect in the middle or preceding (either or not migrated) boxes inside the setting.
Well yes ;-) when I tested this for the headers and footers in latex it took me some time to get it right, so it is not something for the casual user but should be used with care. Btw: we naturally take also other solutions. Some attribute or similar would be fine too. The main point is to have something that allows to disable linking of header and footer and doesn't rely on the box level, which we can't control there. -- Ulrike Fischer https://www.troubleshooting-tex.de/
On 1/11/2021 8:08 PM, Ulrike Fischer wrote:
Am Mon, 11 Jan 2021 19:11:16 +0100 schrieb Hans Hagen:
After updating pdftex i tested that feature (somewhat stupid example as we don't use this link command in context):
How do you make breakable links then?
so, this flag is somewhat unpredictable in the sense that it influences the next box at the upper level and has no effect in the middle or preceding (either or not migrated) boxes inside the setting.
Well yes ;-) when I tested this for the headers and footers in latex it took me some time to get it right, so it is not something for the casual user but should be used with care.
It will be: \protected\def\pdfrunninglinkoff{\pdfextension linkstate 1 } \protected\def\pdfrunninglinkon {\pdfextension linkstate 0 } So, a more generic linkstate whatsit (instead of two different ones). Only values 0 and 1 have meaning.
Btw: we naturally take also other solutions. Some attribute or similar would be fine too. The main point is to have something that allows to disable linking of header and footer and doesn't rely on the box level, which we can't control there.
I think there's no need to be more clever when this hack works ok for latex and, as you mention, it's not meant for users. All this pdf stuff is already more than 20 years old and never was much of an issue anyway: no need to touch code in many places with the danger of introducing side effects. Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
Am Tue, 12 Jan 2021 12:59:55 +0100 schrieb Hans Hagen:
It will be:
\protected\def\pdfrunninglinkoff{\pdfextension linkstate 1 } \protected\def\pdfrunninglinkon {\pdfextension linkstate 0 }
Sounds good. How can one test if the extension is there? Do one has to test against the luatex version or is there something like a \ifdefinedextension test? -- Ulrike Fischer http://www.troubleshooting-tex.de/
On 1/12/2021 3:07 PM, Ulrike Fischer wrote:
Am Tue, 12 Jan 2021 12:59:55 +0100 schrieb Hans Hagen:
It will be:
\protected\def\pdfrunninglinkoff{\pdfextension linkstate 1 } \protected\def\pdfrunninglinkon {\pdfextension linkstate 0 }
Sounds good. How can one test if the extension is there? Do one has to test against the luatex version or is there something like a \ifdefinedextension test?
When Luigi has pushed the code in svn the development_id will be bumped so you can check a test version with: status.development_id which currently is 7395. That is the most detailed info the engine provides (and i normally use that one when I need to adapt). Or you can do something: \ifnum\directlua{tex.print(node.whatsits()[32] == "pdf_link_state" and 1 or 0)}=1 YES \else NOP \fi Or whatever suits your system best. It's no big deal to wrap that lua call in a macro. Then, when there is a new release ypou can use the version number. We don't bump version numbers unless we release. The next bump will quite likely be the next texlive release. Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
On Tue, Jan 12, 2021 at 3:51 PM Hans Hagen
On 1/12/2021 3:07 PM, Ulrike Fischer wrote:
Am Tue, 12 Jan 2021 12:59:55 +0100 schrieb Hans Hagen:
It will be:
\protected\def\pdfrunninglinkoff{\pdfextension linkstate 1 } \protected\def\pdfrunninglinkon {\pdfextension linkstate 0 }
Sounds good. How can one test if the extension is there? Do one has to test against the luatex version or is there something like a \ifdefinedextension test?
When Luigi has pushed the code in svn the development_id
just done the commit revision 7396 into experimental. -- luigi
participants (4)
-
Hans Hagen -
Linas Stonys -
luigi scarso -
Ulrike Fischer