Are changes to \fontdimen global? Why so?

@Skillmon yes, because they are

@DavidCarlisle just tripped over it and now am wondering why this design choice was made. Sometimes DEK is a riddle to me.

@Skillmon well it might just be due to memory constraints in machines of the era but more generally font dimens live mostly at the level of node lists in boxes, so grouping would complicate things, especially in math mode where there are lots of groups but the font dimens are not looked up until the end of the math list

@DavidCarlisle guess I don't know enough about the internals... Thank you very much for the explanation. I'm going to bed now. Good night!

night same here I guess...

@DavidCarlisle Hm. I certainly have spaces before almost all page numbers. Do you get spaces in the log with something like

\documentclass{article}
\begin{document}
abc\newpage \wlog{blb}
abc\newpage \wlog{blb}
abc \wlog{blb}

\end{document}

@UlrikeFischer yes:

 [1

{/usr/local/texlive/2018/texmf-var/fonts/map/pdftex/updmap/pdftex.map}]
blb
 [2]
blb
blb
 [3]

@UlrikeFischer if I just run pdflatex testfiles-pdftex/soulutf8-test2.lvt "by hand" from the test-oberdiek directory then the terminal shows

[6] (/usr/local/texlive/2018/texmf-dist/tex/latex/lm/ts1lmr.fd) [7] [8]
[9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23]
[24]

@UlrikeFischer with a linebreak and no space before [24] but that depends on the path to the fd file.... (@JosephWright)

@UlrikeFischer @JosephWright I wonder if l3build ought to have a way of saying "use these files from the search tree" then if I listed pdftex.map and ts1lmr.fd they would be found by kpsewhich and copied to the test directory before the run (to save checking frozen versions in to a local support tree) then the log reports for those files will always use the local directory and not require tricky path normalisation.

@DavidCarlisle but why should this affect the log? There are messages from qstest between the single pages. When I use abc\newpage \immediate\write200{} abc instead of \wlog the page number is not indented. Perhaps the test is really doing something different for you.

@UlrikeFischer the log version of [23] and [24] is:

Package qstest Info: Passed: string-L-driver-an on input line 315.
Package soulutf8-test Info: * Driver sy on input line 315.
Package soulutf8-test Info: * Version: soulutf8 on input line 315.
Package soulutf8-test Info: * Version: soul + patch on input line 315.
Package soulutf8-test Info: * Version: original soul on input line 315.
 [23

]
Package qstest Info: Passed: string-L-driver-sy on input line 315.
Package soulutf8-test Info: * Driver soulH on input line 315.
Package soulutf8-test Info: * Version: soulutf8 on input line 315.

with a space before 23 but a blank line before 24.

I have

Package qstest Info: Passed: string-L-driver-soulH on input line 315.
 [24]

no blank line. This looks as if something it writing a space or something else to the log for your.

@UlrikeFischer I think the log white space is reflecting the terminal version, what do you get on the terminal, i assume it does not wrap at 24?

@UlrikeFischer I do get a space before [24] if I do cp /usr/local/texlive/2018/texmf-dist/tex/latex/lm/*fd .

@DavidCarlisle yes, my terminal looks like this:

(d:/texlive/2018/texmf-dist/tex/latex/lm/ts1lmr.fd) [7] [8] [9] [10] [11]
[12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24]

Package hyperref Warning: Token not allowed in a PDF string (Unicode):
(hyperref)                removing `math shift' on input line 316.


Package hyperref Warning: Token not allowed in a PDF string (Unicode):
(hyperref)                removing `math shift' on input line 316.

[25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39]

@UlrikeFischer and my terminal looks like

(./ot1lmr.fd) (./omllmm.fd) (./omslmsy.fd) (./omxlmex.fd) [1] [2] (./t1lmtt.fd)
[3] [4] [5] [6] (./ts1lmr.fd) [7] [8] [9] [10] [11] [12] [13] [14] [15]
[16] [17] [18] [19] [20] [21] [22] [23] [24]

@UlrikeFischer so do you have a space before [12] in your log?

@DavidCarlisle no. Looks really as if the terminal output is mirrored in the log.

@UlrikeFischer so copying the fd files (or inputting them early) looks like one way, or forcing a linebreak always by putting \wlog{zzz} into te page header somewhere or....

@UlrikeFischer or we get @JosephWright to remove white space before [page number] at start of lines in l3build....

@DavidCarlisle he will have to handle also

[9
]

@DavidCarlisle in luatex we could change the start_page_number callback.

@UlrikeFischer yes but that's from messages in the output routine so not depending on system dependent paths isn't it the only diffs I was getting in the normalised logs were white space at start of line before [x] (x=6,9,12,24)

@UlrikeFischer we could, but if we need to fix it anyway for pdftex then...

@UlrikeFischer For a minute, I read "Tolkien"!

:)

@DavidCarlisle Doable ...

@UlrikeFischer That I could pick up, I guess

@DavidCarlisle We can do that if we want: they are relatively clear

@DavidCarlisle @JosephWright Imho this would quite good if it doesn't get too slow. It should be not so difficult to build up a standard list of problematic files, it could be shared, and extended when needed.

@PauloCereda ;-)

@UlrikeFischer Right ... I'll think about it

@DavidCarlisle I messed up the pagegrid test (forgot to update the tlg), should be okay at next push.

@DavidCarlisle I changed the embedfile-test3 yesterday evening (redefined \pdf@filemoddate locally to output nothing). So please retry. If is still fails we will have to look ...

@PauloCereda the bloke next door:-)

@DavidCarlisle Clean-up on my blog is interesting: I'm finding lots of typos and the like

@DavidCarlisle Being able to bulk edit is handy

@UlrikeFischer @JosephWright the same thing explains the space before (hycolor-test1.aux) the space comes or goes depending on whether I copy /usr/local/texlive/2018/texmf-dist/tex/latex/graphics-def/pdftex.def locally

@DavidCarlisle I think the technical bit is done bar sorting a better appearance/front page

@DavidCarlisle Hmm

@JosephWright we avoid all these problems in the base tests by not searching the local tree:-)

@DavidCarlisle Very true

@DavidCarlisle so integrate hyperref and hycolor in the kernel ;-).

@UlrikeFischer well now that you mention that.....

@UlrikeFischer @JosephWright list of diffs and comments on reason:

white space before (zzz.aux)
./build/test/hycolor-test1.luatex.diff
./build/test/hycolor-test1.xetex.diff
./build/test/hycolor-test2.luatex.diff
./build/test/hycolor-test2.xetex.diff
./build/test/hycolor-test3.luatex.diff
./build/test/hycolor-test3.xetex.diff

file different length (line endings?) so diffs everywhere
./build/test-config-noxetex/embedfile-test3.luatex.pdf.diff
./build/test-config-noxetex/embedfile-test3.pdftex.pdf.diff

extra utf8 (probably my setup)
+    defining Unicode char U+0237 (decimal 567)

@DavidCarlisle I guess for the hycolor tests one can simply force xcolor to load earlier. embedfile I need to see the log/tpg. selinput can perhaps load the definitions earlier.

@UlrikeFischer I just mailed you mine for comparision.

@DavidCarlisle will check. Simply adding xcolor to hycolor 1 doesn't work ;-(. The first tests are for the case without xcolor, and they explode ..., so one would have to split the test in two.

@UlrikeFischer yes I think we need to lose the white space either via log normalisation or by copying the files locally, while we could construct the tests not to need that I don't think that's document-able as a test mechanism in general.

@DavidCarlisle the tpf/tlg are like mine (not binary equal probably because of the line ending, but the text is ok). Does l3build really complain? What fc from l3build do you get?

@DavidCarlisle copying fd-files and similar around is imho okay, but I don't know if I really want to copy large packages. Heiko is doing often all tests in the preamble. For a test system based on "check for errors" this is okay, but imho a bit of rewriting for a log-based is acceptable.

@UlrikeFischer ther was no diff in that zip, I sent the wrong thing, hang on...

@UlrikeFischer try again:-)

@UlrikeFischer not being binary equal means that the filelength and checksum entries differ and then the xref table at the end is completely different

@UlrikeFischer yes in most cases I think losing white space at the start of lines in the log will fix the issues. I suspect l3build should at least have an option to do that or maybe always do it (@JosephWright)

@DavidCarlisle well the more obvious difference is that your luaotfload is older than mine. Didn't you get the update to 2.93?

@UlrikeFischer er pass, let me check (probably I'm pulling it from the wrong place) but that isn't the main issue as I get essentially the same diff for pdftex embedfile test

@UlrikeFischer ah:

$ kpsewhich --all luaotfload.sty
/home/luaotfload/texmf/tex/luatex/luaotfload/luaotfload.sty
/usr/local/texlive/2018/texmf-dist/tex/luatex/luaotfload/luaotfload.sty

That is I'm pulling from your github source but haven't updated recently (I think now you have pushed from ctan I'll take that directory off my path...)

@DavidCarlisle I have no problems with pdf-tests in tagpdf on travis. So imho there is not a general problem with line endings in pdf between linux and windows. But you are naturally embedding the embedfile.dtx from your checkout, and this is different to mine. So how to normalize this resource?

@UlrikeFischer simplest would be to use a different embedded file, checked in with fixed line endings. (I think)

@UlrikeFischer seems git has an option not to mess with line endings so we could set that for this repo? (force unix line endings on everyone?)

@DavidCarlisle I replaced the embedfile.dtx with the one from the sources in texlive, and now I get different tpf's for test3. I pushed this. Could you check? And I will have to check what happens if I checkout on my laptop.

@DavidCarlisle but no hurry, have to do some shopping now anyway.

@UlrikeFischer passes now, thanks

@DavidCarlisle I have now added a .gitattribute to force this file to have LF-lineending. It contains also the default setting * text=auto (from help.github.com/articles/dealing-with-line-endings). I hope this doesn't lead to new problems ;-).

I was looking at multiline comments in latex and stumbled upon this page en.wikibooks.org/wiki/LaTeX/…

it seems that importing verbatim package and doing

\begin{comment}
Commented stuff
\end{comment}

works but the commented stuff is still parsed for latexy stuff

so if there is large amounts of math inside the commented stuff it will all be processed, just that it won't be a part of the final output

is my interpretation correct?

thanks :)

@GaurangTandon it shouldn't be, the content should be read as if it was a verbatim environment.

@DavidCarlisle ohh.. right

i was confused by the line "nother drawback is that content is still parsed and possibly expanded, so you cannot put anything you want in it (such as LaTeX commands)." on that linked page

@GaurangTandon the comment package defines a similar construct as well

hmm that's nice

@GaurangTandon well that page or I are wrong then:-)

I believe you're certainly right :)

@GaurangTandon just looked at the page, that comment about the content being parsed refers to using \def\comment#1{...}...\comment{foo} instead of the verbatim/comment environment

@DavidCarlisle ohhh...i thought it referred to both that \def and verbatim environment

@GaurangTandon like the TeXBook, it's easier to parse the documentation if you know the answer first:-)

@DavidCarlisle yeah :P

Interesting, for once I come by some chemistry, well, biology. What is the recommended method for typesetting say pH 7.4, I'm assuming this is not siunitx territory?

@daleif It's not, you are right

@daleif I'd say pH~$7.4$ or (possibly) $\mathrm{pH} 7.4$, depending on your exact view on the handling of such symbols

@JosephWright I'll just use pH~$7.4$ then , thanks. Was looking at chemmacros, but I only need pH so...

Is there a neat and clever way to convert pt into mu? Up till now I only came up with doing something like \setbox0\hbox{$\mkern1mu$} to get the width of a mu and use that for calculations.

@Skillmon divide the length by 18 \fontdiment 5 (or whichever is 1em)

@Skillmon 6 not 5 (5 is ex:-)

@Skillmon \mutoglue?

@JosephWright rather gluetomu I think

@DavidCarlisle Oh, yes, that way around ...

@JosephWright oh.

@JosephWright thanks

@JosephWright it's not in the TeXbook. Was it added by eTeX?

@Skillmon Yes

@Skillmon texdoc etex

@Skillmon That's why @DavidCarlisle didn't think of it straight away: too modern

@JosephWright that and the fact that it answers a different question (but yes:-)

@DavidCarlisle :)

@DavidCarlisle is 18 mu == 1em?

@Skillmon 1/18em from \textfont2 if I recall correctly

@JosephWright but \gluetomu doesn't get the calculation right, it just strips the pt and adds mu to it.

\ddanger There are 18 mu to an em, where the em is taken from family~2
(the math symbols family). In other words, ^|\textfont|~|2| defines the em
value for |mu| in display and text styles; ^|\scriptfont|~|2| defines the
em for script size material; and ^|\scriptscriptfont|~|2| defines it for
scriptscript size.

@Skillmon ^^

@Skillmon I'll be honest, I've not looked at the detail of these commands

@JosephWright it's so new, you have nit had time

The commands \gluetomu and \mutoglue convert glue into muglue and vice
versa by simply equating 1 pt with 1 mu , precisely what TEX does (in addition
to an error message) when the wrong kind of glue is used.

@Skillmon ^^^

@JosephWright I don't get the usefulness of these in this case, it's trivial to code this in macros :(

@Skillmon Not everything is that useful ...

@Skillmon \outer ...

@DavidCarlisle ^^^

@JosephWright \outer has to be useful! It must be! (Because I still never used it and have no idea what it should do, it simply must be useful)

@Skillmon It's not, really, other than for deliberately forcing an error

@JosephWright sometimes forcing an error is all we want.

@Skillmon Try \def\foo#1{\newcount#1} in plain ...

@Skillmon That's easy enough: you can use an undefined csname

@Skillmon no, \outer has no useful use cases (even though I use it in bm package::-)

@DavidCarlisle but if you use it, it must be useful!

@Skillmon no.

@DavidCarlisle how do I best get the em of \textfont2?

@Skillmon \fontdimen 6 \textfont2

@DavidCarlisle forgot that \fontdimen takes the used font as argument...

Today I'm stupid

(it took me 30min to write a 3 lines email today...)

@Skillmon \outer is fully documented on site here:

@DavidCarlisle ooh

Some TeX Developments

@PauloCereda Moving to GitHub Pages real soon now

@JosephWright ooh

@PauloCereda that bot you run how are you running that? Is it similar to the capabilities of lrrbot.mrphlip.com

@daleif Oh it's a bot made for SE sites: github.com/javachat/oakbot

@Skillmon Thirty minutes for a haiku would be astoundingly fast …

@HaraldHanche-Olsen let's just say it wasn't a very complicated message.

@JosephWright @UlrikeFischer did we used to normalise away the test name? this would make the tests pass except it just looks for (.aux) not (hycolor-test1.aux)

@DavidCarlisle Not sure that I understand what you mean, but imho the gsub will not affect a line like this:

) (hycolor-test1.aux)

@DavidCarlisle Yes, we did: it was an issue in some places

@UlrikeFischer I mean that line did something useful when it was written but now does nothing (so the test fails at my side:)

@JosephWright so that test for (.aux) needs relaxing. I'm tempted to say remove all white space at start of line

@DavidCarlisle Ah, right: I probably missed that one

@DavidCarlisle but the line (at least here) begins with a ). Doesn't the gsub anchors a space at the begin?

@UlrikeFischer no that's the second input right at the end it's the earlier one that is at the start of a line that fails:

@UlrikeFischer first and last lines in this bit, it is the first line that is the problem:

 (./hycolor-test1.aux)
\openout1 = hycolor-test1.aux

LaTeX Font Info:    Checking defaults for OML/cmm/m/it on input line 248.
LaTeX Font Info:    ... okay on input line 248.
LaTeX Font Info:    Checking defaults for T1/cmr/m/n on input line 248.
LaTeX Font Info:    ... okay on input line 248.
LaTeX Font Info:    Checking defaults for OT1/cmr/m/n on input line 248.
LaTeX Font Info:    ... okay on input line 248.
LaTeX Font Info:    Checking defaults for OMS/cmsy/m/n on input line 248.
LaTeX Font Info:    ... okay on input line 248.

@DavidCarlisle Ah. sorry. Is the difference between (./hycolor-test1.aux) and (hycolor-test1.aux) also a problem?

@UlrikeFischer no that gets normalized away, the only thing in the diff is the space

@DavidCarlisle Joseph could simply remove all spaces ;-).

@UlrikeFischer would make it hard to test error messages (unless you are German of course)

@UlrikeFischer but I can't see any harm in always removing white space from the start of a line, it may change some existing tlg files but would be a one-off hit.

@DavidCarlisle I would have no problems with it. One could make it optional with some boolean in the build.lua if wanted.

@UlrikeFischer @JosephWright a less aggressive normalisation which would also work for all the cases here is to remove the space from start-of-line single-space [-or-(

@DavidCarlisle OK, I'll look at it when I can

@DavidCarlisle It was an issue where the spaces were deliberate ... or where they alter line length for wrapping

@JosephWright thanks

@JosephWright yes I remember you saying the space was kept on purpopse but ^ ([%[%(]) -> %1 is probably safe enough.

@DavidCarlisle Yeah, sounds OK: I'll see if I have time later

@DavidCarlisle Currently re-doing blog conversion: I want a reaonably-clear log of changes, and it got a bit messy. I know what I'm doing this time ...

@DavidCarlisle, @egreg, @UlrikeFischer Have you seen tex.stackexchange.com/questions/458507/… and related? Thoughts?

@DavidCarlisle Also tex.stackexchange.com/questions/458122/…

@JosephWright Yes, just thinking about it. The \par inside the hbox looks a bit odd. Also even if it is needed: it seems a bit against the spirit of expl3 to use "\par" in the code. Why not \tex_par:D?

@UlrikeFischer Because if used with l3galley we need to close the logical paragraph here. Think we might also have been worried about the case where TeX inserts \par, which is always that token (see comments in l3final)

@JosephWright but beside this, the OP could test if for ifinner in his definition.

@UlrikeFischer There is that, yes

@UlrikeFischer We could move the \par to the vbox definition, then it can be dropped from the colour group and we are in the same place as \mbox in 2e

@JosephWright it may not be a latex3 issue, maybe what enotez is doing is odd.

@StrongBad It's worth exploring, at least

@StrongBad you could probably use something like \def\foo{\def\par{\ifinner\@@par \else Hello World\global\let\par\@@par\par\fi}}.

@JosephWright sounds more logical. Why should a color group end with a \par?

@UlrikeFischer When you have a vertical box, TeX adds the internal \par primitive, but that doesn't tidy up any structures we've added: LaTeX2e also has to do this for vboxes

@JosephWright yes, but this is what I meant: you need it for vertical boxes so put it there.

@UlrikeFischer that seems to do it.

@egreg why is \global\let\par\@@par bad?

@UlrikeFischer Was meant to be easier .. sigh

@JosephWright ;-).

@UlrikeFischer I guess I'll change it

@JosephWright But finish your blog business first ...

@StrongBad I just got back and haven't followed the thread but it looks bad to me:-)

@StrongBad if you do that inside a list for example you will kill the list item paragraph shaping as that is stored in a local definition of \par

I can't even remember how I got signed up to academia.edu, is anyone else on it and does it do anything other than send email saying The name "David Carlisle" is mentioned by a well-known author on Academia. view-your-mentions where the button says you need to pay something,

@DavidCarlisle ;-).

@StrongBad I'll likely adjust the expl3 code for the next release (some time this week)