Hi, the new `glyph_info` callback is called in two pretty different cases: in `short_display(_n)` where a pretty short representation of the actual output characters is required, and in `print_font_and_char`, which creates the representation for `print_node_list`. Here, more details can be useful, e.g.: Which variant of a character is used, are displacements applied etc. These could be added through `glyph_info`, but then these additional fields are also printed in `short_display`, leading to significantly worse overfull warnings etc. This could be improved if `glyph_info` could return different values in different situations. So I suggest to add an additional parameter to the `glyph_info` callback which states if the current context could handle longer output. A possible implementation is attached. Best regards, Marcel
Hi,
I noticed that whatsit subtype "write" has changed "data" field type.
Documentation says "data -> table representing the token list to be written"
but when I print it I see it as a string with LuaTeX, Version 1.10.0 (TeX Live 2019):
HERE
On 24 Oct 2019, at 13:10, Linas Stonys
Hi, I noticed that whatsit subtype "write" has changed "data" field type. Documentation says "data -> table representing the token list to be written" but when I print it I see it as a string with LuaTeX, Version 1.10.0 (TeX Live 2019): HERE
nil : whatsit 1> \foo\fee With LuaTeX, Version 1.07.0 (TeX Live 2018/W32TeX) is ok: HERE
nil : whatsit 1> table: 02D87EC8 Minimal example: \write1{\string\foo \unexpanded{\fee}}% \directlua{ local head = tex.nest[tex.nest.ptr].head local tl = node.tail(head) print ("HERE", tl, tl.data) } \bye
The real world example will be: \documentclass{article} \usepackage[color=no]{nodetree} \nodetreeoption[channel]{log} \nodetreeregister{preout} % pre_output will rise an error trying to print whatsits data field
\begin{document} \makeatletter \protected@write \@auxout {}{\string\@gobble\string\fee} %% this is ok \protected@write \@auxout {}{\string\@gobble\protect\foo} %% but this will rise \foo undefined error \makeatother \end{document}
And this is very strange that accessing whatsits (subtype "write") "data" field executes it.
The reason is that function get_write_direct_value (lnodelib.c:1652) provides expanded tokenlist version by function expand_macros_in_tokenlist (lnodelib.c:1652; defined in extensions.c:512). Maybe a bit changed behaviour with providing unexpanded tokenlist be more useful and flexible working with whatsit data from lua side. In such case minimal changes could be: to use by get_write_direct_value a modified version of expand_macros_in_tokenlist with different token scan changed from scan_toks(false, true) to scan_toks(false, false) (extensions.c:541). Regards, Sigitas
Hi, There was already several questions about "user_defined" whatsits and I know that sometimes it can still influence the output (like there will be no font kern between two letters if there is a whatsit). I'm analyzing all available methods for marking output contents for tagged pdf or xml conversions. Now I noticed that it disables \last.. elements (like \lastskip, \lastpenalty) in vertical mode. In horizontal mode it doesn't influence \lastskip. So is it a bug? And could it be fixed in the future or this behavior will stay for ever? minimal example %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \directlua{ USER_MARK = node.new("whatsit","user_defined") USER_MARK.type = 115 USER_MARK.value = "my node" function writemark() local usermark = node.copy(USER_MARK) node.write(usermark) end } \def\addwhatsit{\directlua{writemark()}} \documentclass{article} \begin{document} \null \vskip 20pt \par \showthe\lastskip %% shows 20.0pt \null \vskip 30pt \par \addwhatsit \showthe\lastskip %% shows 0.0pt \null \hskip 10pt \addwhatsit \showthe\lastskip %% shows 10.0pt \end{document}
On 10/28/2019 2:04 PM, Linas Stonys wrote:
Hi, There was already several questions about "user_defined" whatsits and I know that sometimes it can still influence the output (like there will be no font kern between two letters if there is a whatsit). I'm analyzing all available methods for marking output contents for tagged pdf or xml conversions. Now I noticed that it disables \last.. elements (like \lastskip, \lastpenalty) in vertical mode. In horizontal mode it doesn't influence \lastskip. So is it a bug? And could it be fixed in the future or this behavior will stay for ever? won't change
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 -----------------------------------------------------------------
participants (4)
-
Hans Hagen -
Linas Stonys -
Marcel Fabian Krüger -
Sigitas Tolusis