@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
@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.
@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....
@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...
@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.
@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 ...
@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
@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.
@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 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)
@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
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?
@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.
@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 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 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
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?
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.
\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.
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.
-- Deal with the fact that "(.aux)" may have still a leading space
line = gsub(line, "^ %(%.aux%)", "(.aux)")
@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)
@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.
@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.
@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 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 ...
@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)
@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
@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 Did not know that, thanks, and it kiiinda solves my problem, i'll have to restructure the command a teensy bit to show up correctly, and it answers my question indirectly. Truely the magician we need my not deserve.