27

This is a followup to a comment of mine posted in 2012. In short, MikTeX does not remove the leading BOM from listings, but TeXLive does, as shown in the following images. The leading BOM effect can be clearly seen by comparing the first line of the output (using System;) in listings produced with MikTeX and TeXLive.

MWE

% The filename is MikTeX-VS-TeXLive.tex

\documentclass[preview,border=12pt]{standalone}

\usepackage{listings,xcolor}
\lstset
{
    language={[Sharp]C},
    backgroundcolor=\color{cyan!20},
    basicstyle=\scriptsize,
    keywordstyle=\color{blue},
    identifierstyle=\color{red},
    breaklines=true,
}

\begin{document}
\lstinputlisting{program.cs}
\end{document}

Output with MikTeX

enter image description here

Output with TeXLive

enter image description here

Questions

What should I do to make MikTeX do the same thing as TeXLive does but without having to use literate?

Bonus question: Is the source code of pdflatex, xelatex, latex used for MikTeX exactly identical to that of for TeXLive? If yes, why do they behave differently? If the source code is different, why are they made differently?

cxw
  • 275
  • 1
  • 3
  • 12
kiss my armpit
  • 36,086
  • On my TeX Live I get the spaces at the beginning; of course I can't test MiKTeX. – egreg Jun 04 '14 at 21:09
  • @egreg: Hmm... it looks weird. We have the same TeX Live I think. – kiss my armpit Jun 04 '14 at 21:11
  • Stymied. I wanted to do something like \newunicodechar{ï}{} and likewise for the rest of the BOM, but this doesn't work because the listings package doesn't like UTF-8 extended characters. – Ian Thompson Jun 04 '14 at 21:48
  • 4
    I can reproduce the behaviour on windows: TeXLive (2012, 2013 and 2014) pdflatex ignores the BOM. It is not related to listings. If I simply input the file and use T1-encoding then I see in miktex ïż£ but nothing in texlive. It looks as if windows binaries of texlive are clever ;-). And it would be worth a feature request to get the same for miktex. – Ulrike Fischer Jun 05 '14 at 07:11
  • @UlrikeFischer I'm not certain about this: the same doesn't happen in TeX Live for Mac OS X, where the BOM is not ignored. – egreg Jun 14 '14 at 21:07
  • Using pdflatex from TeX Live 2014 on Linux, BOM is not ignored. – mvkorpel Jun 25 '14 at 14:03
  • Nothing different with TeX Live 2014 on Windows. – kiss my armpit Jun 26 '14 at 21:35
  • @kissmyarmpit has anything changed here? Is the situation still the same? – Paul Gessler Apr 15 '15 at 17:38
  • 1
    I can't comment -- thus as an answer to the first part of the bonus question: From experience, I'd say there are many differences between MikTeX and TeXlive implementations, especially when handling external files: MikTeX also supported including files with added extension using \include{filename.tex}, while TeXlive doesn't like that: No file test.tex.tex. MikTex did support downloading packages during compilation, while TeXlive didn't. – phi1010 Sep 20 '17 at 06:02
  • 2
    I cannot reproduce this issue (the spacing problem) using: Windows MikTex with TeXstudio, encoding program.cs as UTF-8-BOM, and using any of: pdflatex, latex or xelatex. The output always looks like your "Output with TeXLive" – jessexknight Oct 13 '17 at 16:47
  • @kissmyarmpit can you upload "program.cs", because in my file saved by Visual Studio, it does not add any BOM to the file. – JoKalliauer Jul 07 '18 at 18:47

1 Answers1

1

Status in 2019

I can run a BOM TeX file concurrently through both systems and my current tests suggest presently there are no differences for the stated historic cause (3 hidden characters i.e. literate={ï}{}0 {»}{}0 {¿}{}0 )

enter image description here

Although there are other differences in file output !

MiKTeX-PdfLaTeX command compiles file as 25.9 KB (26,610 bytes) via 

miktex-pdftex.exe $synctexoption --undump=pdfLaTeX $fullname

The 2018 TeX Live one is smaller 24.5 KB (25,145 bytes) 

pdflatex.exe $synctexoption $fullname

Both pdf files appear identical in scale and visual content.