Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support request for pTeX-specific validation test #103

Closed
aminophen opened this issue Oct 25, 2019 · 6 comments
Closed

Support request for pTeX-specific validation test #103

aminophen opened this issue Oct 25, 2019 · 6 comments

Comments

@aminophen
Copy link

I'm considering about introducing l3build test files into development repo of pTeX and friends. However, current l3build-check.lua strips some pTeX-specific log entries:

    -- Remove 'normal' direction information on boxes with (u)pTeX
    -- Remove '\displace 0.0' lines in (u)pTeX

I guess these are intended to reduce diffs between pTeX and Western TeX, but for us we need only pTeX-specific tests. Actually we'd like to know what would change in the process of pTeX refinement. (e.g. is '\displace 0.0' correctly inserted in the correct place?)

Is it possible to provide some way of not stripping off these logs?

@josephwright
Copy link
Member

I'm not 100% sure I follow. My impression, purely from comparing pdfTeX and (u)pTeX logs, was that \displace 0.0 was always going to be a no-op, and that any 'real' information would be \displace <some-other-value>. Are there places that (u)pTeX doesn't add this at all, such that the difference is diagnostic?

It's of course possible to sort out selective normalisation: I can do that by checking if the default engine is (u)pTeX, and suppressing this normalisation if it is.

@josephwright
Copy link
Member

Similar comment for yoko direction: all lines get a direction, so any that are not yoko will show?

@aminophen
Copy link
Author

\displace 0.0 was always going to be a no-op

No, consider the following example for plain eptex:

\tracingonline1
\showboxdepth10000
\showboxbreadth10000
\setbox0=\vbox{\ybaselineshift 10pt\relax あaい}\showbox0
\box0
\bye
..\displace 0.0
..\JY1/mc/m/n/10 あ
..\displace 10.0
..\glue(\xkanjiskip) 2.40553 plus 1.0 minus 1.0
..\OT1/cmr/m/n/10 a
..\displace 0.0
..\glue(\xkanjiskip) 2.40553 plus 1.0 minus 1.0
..\JY1/mc/m/n/10 い

\displace 10.0 lowers "a" by 10.0pt, and \displace 0.0 returns the reference point (= goes up by 10pt) of "い".

yoko direction

\setbox0=\vbox{\tate\hbox{\yoko い}}\showbox0
..\dirbox(4.81108+4.81108)x9.16443, tate direction
...\hbox(7.77588+1.38855)x9.62216, yoko direction

I hope this kind of encapsulation can be tested as well...

@aminophen
Copy link
Author

\displace 0.0 ... Are there places that (u)pTeX doesn't add this at all, such that the difference is diagnostic?

Previous versions (near TL2017 or older) did not emit \displace 0.0 in some necessary places, however, recent version of pTeX adds (or, should add) \displace 0.0 or \displace <some-other-dimen> everywhere.

yoko direction: all lines get a direction, so any that are not yoko will show?

For now I can't think of, but some old (near 2011?) version did not show yoko direcetion in some places due to a bug.

@josephwright
Copy link
Member

What happens in TL'19? We are not keen on trying to cover multiple engine versions retrospectively ...

That said, the change here actually looks pretty trivial from the code point of view.

@aminophen
Copy link
Author

pTeX and friends in TL19 still need some more refinements, which are raised as open issues on https://github.com/texjporg/tex-jp-build/issues. For now we are going to improve automatic insertion of glue penalties between Japanese and Latin characters (texjporg/tex-jp-build#85). That place is a candidate for insertion of displacement node, so removing \displace 0.0 from log means that we cannot use l3build for detecting what we actually changed.

josephwright added a commit that referenced this issue Oct 27, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants