3 
\documentclass{article}
\usepackage{xhfill}

\begin{document}
Foo \xrfill[0pt]{30pt}[black]
\end{document}

When rendered by LuaLaTeX, this produces a thick black line with clearly visible vertical stripes:

LuaLateX output

When rendered by XeLaTeX, the line is solid as expected.

This seemed to come and go at first. I went down several false paths, including the % !TEX program string, newlines, LaTeX Workshop vs TexShop, and clearing aux files.

Edit: It may be viewer-related. I can see lines in Preview.app and Tex Shop (which may use an embedded Preview pane), but not in Chrome. When viewing with Preview, I can consistently toggle stripes/no stripes by building with XeLaTex/LuaLaTex.

Environment: macOS Big Sur 11.2, MacTeX-2020, TeXShop 4.58, all packages up-to-date via TeX Live.

Improve this question
2
  • Hmmm. I see the lines with xetex but not luatex, except in one of my pdf viewers, where the lines show with both. I suspect the viewer.
    – Thérèse
    Feb 21, 2021 at 21:31
  • @Thérèse Interesting! I have tried a couple of different viewers and will update my question with the results.
    – knite
    Feb 21, 2021 at 21:47

1 Answer 1

Reset to default
3

I don't see the stripes in xpdf but I do in firefox/pdf.js rendering.

\xrfill makes a rule out of repeated small adjacent panels, each separately coloured, which is asking a lot of the pdf renderer. It is simpler to render a single rule with a single colour as in the example below

enter image description here

\documentclass{article}
\usepackage{xhfill}

\begin{document}
Foo \xrfill[0pt]{30pt}[black]

\bigskip

Foo \textcolor{black}{\leaders\vrule depth 0pt height 30pt \hfill}

\end{document}
Improve this answer
4
  • Thank you, this solves the actual problem. However, I still see inconsistent rendering between Xe and Lua in the same viewer, which suggests that their output is different enough to change rendering for some viewers. I'd love to report this to the relevant maintainers if it's a real bug.
    – knite
    Feb 21, 2021 at 22:55
  • @knite I do not think it is a bug in the engines. If you specify adjacent panels you can get rendering artefacts like this, see thousands of comments about vertical or horizontal rules being affected by colortbl coloured backgrounds in any tex forum, that is essentially the same issue.
    – David Carlisle
    Feb 21, 2021 at 23:21
  • The rendering artifacts occur with one engine but not the other - to me this suggests that the engines are doing things differently such that one of them may be "wrong".
    – knite
    Feb 21, 2021 at 23:39
  • 1
    they may be different in fractional rounding differences but how that affects snapping to different pixel boundaries in different viewers depends on the document and which viewer you use, I don't think you can say which one is right and which is wrong (and some pdf viewers are a lot better at avoiding this than others) But feel free to report if you wish, don't let me stop you. (but I have had this issue since I added color support to latex in 1994 and I haven't seen a way to avoid it so far other than avoid writing adjacent panels)
    – David Carlisle
    Feb 21, 2021 at 23:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .