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

Inconsistent vertical spacing/distance between pdfengines #10371

Closed
Disonantemus opened this issue Nov 9, 2024 · 6 comments
Closed

Inconsistent vertical spacing/distance between pdfengines #10371

Disonantemus opened this issue Nov 9, 2024 · 6 comments
Labels

Comments

@Disonantemus
Copy link

Explain the problem.

Testing 3 popular pdfengines supported by pandoc, I did notice, that there are big differences between how is managed the vertical space (distance), specially between title and next text, this is specially awful in typst. Maybe is related to templates.

Image made from screenshots of the PDFs generated by pandoc made at fullscreen in zathura (width mode), joined in gimp.

pdfengines compared

From the image:

  • pdflatex has the same vertical space between title and different kind of texts (regular text, list, comments).
  • typst & pdfroff both has a longer vertical space between title and comment, near double or more than regular distance.
  • typst has very small vertical space between title and any text, a lot smaller than pdflatex & pdfroff; this seems to me unnatural and forces to edit md file and use an   bellow every title. This is clear because both pdflatex and typst has almost same font size, but distances are very different.

Commands to create PDFs:

$ pandoc a.md --pdf-engine pdflatex -o pdflatex.pdf
$ pandoc a.md --pdf-engine typst -o typst.pdf
$ pandoc a.md --pdf-engine pdfroff -o pdfroff.pdf

Sample file:

$ cat a.md
# Title

regular text

# Title

1. list item
1. list item

# Title

> comment

Pandoc version?
Latest release

$ pandoc --version | head -3
pandoc 3.5
Features: +server +lua
Scripting engine: Lua 5.4

$ pdflatex --version | head -2
pdfTeX 3.141592653-2.6-1.40.26 (TeX Live 2024/Arch Linux)
kpathsea version 6.4.0

$ typst --version
typst 0.12.0 (737895d7)

$ groff --version | head -1
GNU groff version 1.23.0

distro: Arch Linux x86_64
kernel: 6.6.52-1-lts
shell: bash 5.2.37
term: tmux
@jgm
Copy link
Owner

jgm commented Nov 9, 2024

I don't consider this a bug, really. Pandoc tries to produce fairly idiomatic output in these formats, and these pdf engines produce different output. (If you want really different output, try weasyprint!) It's not a goal of the project for these to look the same.

@Disonantemus
Copy link
Author

Not the same, it's obvious that different pdfengines use different fonts and sizes, but it seems clear to me, that typst has an unusual small distance between Title and regular text (or List).

There's something that I can change in templates or somewhere else to adjust that?

For pdflatex it's ok this:

# Title

regular text

But in typst I need to add a "\" to have something similar:

# Title
\
regular text

I really love typst, because is 100x smaller I got almost the same quality as pdflatex, I also like groff, but is a little bit rough.

@jgm
Copy link
Owner

jgm commented Nov 11, 2024

I agree with you that typst's spacing seems too small. Here's a sample I just generated on the online typst.app:

Screenshot 2024-11-10 at 9 21 32 PM

It seems this is intentional: I found this in the typst documentation:

When a paragraph is adjacent to a block that is not a paragraph, that block's above or below property takes precedence over the paragraph spacing. Headings, for instance, reduce the spacing below them by default for a better look.

But unfortunately, the heading element doesn't have a below property that you can adjust.

I eventually figured out that you can do this:

#show heading: set block(below: 1em)

@iandol
Copy link
Contributor

iandol commented Nov 11, 2024

There's something that I can change in templates or somewhere else to adjust that?

Yes, you can fully edit the Typst template to your hearts desire. Export default.typst and then add the Typst set and show rules to tweak your layout -- or use Pandoc's header-includes to inject code from metadata into the template without needing to edit it. You can use the online editor to play in realtime with the layout:

https://typst.app/project/rMRTsaf85SDvafLW1wZlQA

@alerque
Copy link
Contributor

alerque commented Nov 11, 2024

I don't consider this a bug, really. Pandoc tries to produce fairly idiomatic output in these formats, and these pdf engines produce different output. (If you want really different output, try weasyprint!) It's not a goal of the project for these to look the same.

I fully agree here, Pandoc should NOT try to normalize the look of the output across different formats, even where drastic differences exist in the default choices of various typesetting engines. The default output should be as generic idiomatic semantic content as the target format allows for.

Of course each user and project is welcome to build on that and include style choices for specific output formats in the conversion process, but the default should be to let the typesetter use its defaults.

@jgm jgm closed this as completed Nov 11, 2024
@alerque
Copy link
Contributor

alerque commented Nov 16, 2024

I happened to be working no something else and wanted to compare some default spacing choices between PDF engines. Here is the Pandoc manual rendered with a few different engines on the same papersize at the same zoom level with straight engine defaults:

image

The SILE engine on the top left is not merged to Pandoc yet but maintained in my fork (see #6088). Otherwise this is straight defaults from Pandoc 3.5 and out of the box settings for each engine. Generated with:

for engine in sile typst lualatex xelatex weasyprint pdfroff; do
	pandoc --print-default-data-file=MANUAL.txt |
		pandoc -V papersize:a4 -t pdf --pdf-engine=$engine -o MANUAL-$engine.pdf
done

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants