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

Documentation LaTeX generation creates files that make pdflatex handle non-ASCII characters incorrectly #12804

Closed
huonw opened this issue Mar 10, 2014 · 14 comments

Comments

@huonw
Copy link
Member

huonw commented Mar 10, 2014

It seems our invocation of Pandoc on some files (e.g. guide-tasks.md) creates something equivalent to:

\documentclass{article}
\usepackage[utf8]{inputenc}
\begin{document}
π
\end{document}

which causes the following error

$ pdflatex unicode-input.tex
[...]
! Package inputenc Error: Unicode char \u8:π not set up for use with LaTeX.

See the inputenc package documentation for explanation.
Type  H <return>  for immediate help.
 ...                                              

l.4 π
[...]

The relevant section of (my) inputenc docs is:

1.3.3 Unicode char ⟨charcode⟩ not set up for use with LaTeX

This is the dreaded error message that one will receive if the document contains an
UTF-8 character that isn’t known to LaTeX. It is quite possible that the character
looks very unsuspicious and is rendered perfectly in the editor.

For example, when entering a Euro symbol from the keyboard one may receive
this error rather than a typeset symbol. But if this happens the reason is simply
that the document doesn’t load a font containing the Euro symbol, e.g., via the
textcomp package. Thus LaTeX does not know how to typeset one and therefore
responds with this error message.

However, even if LaTeX can type that character in question it may not
have been set up in which case you would need to do that yourself via
\DeclareUnicodeCharacter. If you provide these declarations for a full font en-
coding then please contribute that work to this package so that others can benefit
too.

@huonw huonw added the A-docs label Mar 10, 2014
@huonw
Copy link
Member Author

huonw commented Mar 10, 2014

I guess this might be a bug in pandoc... I don't really know. (The encoded character is U+03C0, i.e. it's not some peculiar pi glyph from a higher plane or anything like that.)

@huonw
Copy link
Member Author

huonw commented Mar 10, 2014

The above file works with both lualatex and xelatex i.e. it's pdflatex specific (which makes sense since the former two are designed for unicode input).

huonw referenced this issue Mar 10, 2014
This restores the old behaviour (as compared to building PDF versions of
all standalone docs), because some of the guides use unicode characters,
which seems to make pdftex unhappy.
@pnkfelix
Copy link
Member

cc me

@pnkfelix
Copy link
Member

@huonw after reading some Q/A sites and finding the following links:

I now have this variant of your file which does seem to render on my copy of pdflatex:

\documentclass{article}
\usepackage[LGRx,T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage{textgreek}
\begin{document}
π
\end{document}

@huonw
Copy link
Member Author

huonw commented Mar 10, 2014

I get the feeling that the comment

The best way to deal with unicode source (especially with non-latin scripts) is really XeLaTeX or LuaLaTeX.

on the first link is the correct solution: we live in a unicode world, so we might as well just use a unicode engine, rather than trying to bash pdflatex into submission. (Especially since we'd need to convince pandoc to output that code somehow.)

@pnkfelix
Copy link
Member

@huonw I don't personally mind depending on XeLaTeX or some other unicode-enabled latex (as long as we select one that has wide support for our hosts, i.e. Mac OS X and Linux ... not sure if Windows/MinGW is as much as a priority as the other two).

@huonw
Copy link
Member Author

huonw commented Mar 10, 2014

XeTeX is bundled with TeX Live, MacTeX, and MiKTeX (see the History below for dates and versions). -- http://en.wikipedia.org/wiki/XeTeX

And some quick browsing suggests LuaTex is supported by those 3 distributions too (not 100% sure about MiKTeX), so it seems that platform support shouldn't be a problem.

@adrientetar
Copy link
Contributor

TeXLive installs all major compilers indeed.

pandoc should use utf8 inputenc by default, see for yourself: default.latex; maybe the version on the bot is too old and doesn't have it. Also iirc latest pandoc parses unicode chars with \DeclareUnicodeCharacter but I'd need to check that up.

@pnkfelix
Copy link
Member

@adrientetar the problem isn't whether utf8 inputenc is used; its that you need to load up other packages to get common non-ascii characters like π. (Compare the original test in the description to the version I found that one can build; both are using \usepackage[utf8]{inputenc}; the differences between them are the other usepackage commands that I had to add)

@adrientetar
Copy link
Contributor

@pnkfelix We can use --include-in-header=header.tex to add packages. Or we can use lualatex by default.

@adrientetar
Copy link
Contributor

BTW, are we really willing to make PDFs for guides? These just seem like quick things that you'd read up rapidly, not sure we need a LaTeX PDF for that.

@brson
Copy link
Contributor

brson commented Apr 21, 2014

@adrientetar IMO we don't need PDFs at all, though I understand the desire to have a printable manual.

@adrientetar
Copy link
Contributor

Fix would be to build with lualatex OR xelatex OR pdflatex (the opposite of what we’re doing now), code is here:
https://github.com/rust-lang/rust/blob/master/mk/docs.mk#L79

lualatex has been endorsed as pdflatex’s successor and ships with texlive since quite some time now.

bors added a commit that referenced this issue Sep 11, 2014
Bugs in pdflatex (#12804) are preventing the guide from landing (#16657). This solves the immediate problem by changing the build system to prefer lualatex, xelatex to pdflatex (which is apparently obsolete). Because the xelatex on the snapshot bot seems to completely ignore the `-output-directory` option, I also had to frob the makefiles a bit for that case.
@steveklabnik
Copy link
Member

I think since we have the preferred latex stuff in the right order, this is effectively good enough.

bors added a commit to rust-lang-ci/rust that referenced this issue Jul 25, 2022
…kril

fix: make file watcher config a drop-down (and clarify the options)

Fixes rust-lang/rust-analyzer#12794

Also renames "notify" to "server", since that's clearer ("notify" is still accepted for compatibility).
bors added a commit to rust-lang-ci/rust that referenced this issue May 30, 2024
fulfill expectations in `check_unsafe_derive_deserialize`

The utility function `clippy_utils::fulfill_or_allowed` is not used because using it would require to move the check for allowed after the check iterating over all inherent impls of the type, doing possibly unnecessary work.
Instead, `is_lint_allowed` is called as before, but additionally, once certain that the lint should be emitted, `span_lint_hir_and_then` is called instead of `span_lint_and_help` to also fulfill expectations.

Note: as this is my first contribution, please feel free to nitpick or request changes. I am happy to adjust the implementation.

fixes: rust-lang#12802

changelog: fulfill expectations in [`unsafe_derive_deserialize`]
bors added a commit to rust-lang-ci/rust that referenced this issue May 30, 2024
fulfill expectations in `check_partial_eq_without_eq`

This is a followup to rust-lang#12804, fixing a similar issue for `derive_partial_eq_without_eq` by using `span_lint_hir_and_then` instead of `span_lint_and_sugg`.

Additionally tests for both `#[allow(clippy::derive_partial_eq_without_eq)]` and `#[expect(clippy::derive_partial_eq_without_eq)]` are added.

changelog:[`derive_partial_eq_without_eq`]: fulfill expectations
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants