Setting margins with «geometry» in LaTeX doesn't work

[Hi-Angel]

Setting page margins with geometry silently ignored upon being converted to an .odt. A minimal reproducible testcase:

\documentclass{article}
\usepackage[top=1cm, bottom=1.25cm, left=4cm, right=1.25cm]{geometry}

\begin{document}

\section{First Section}

\end{document}

Here the left margin being set the giant 4cm — however upon converted to .odt the left margin becomes set to zero.

The command to convert is pandoc -f latex -t odt -o output.odt test.tex

Pandoc version is 1.15.0.6

[KurtPfeifle]

If you want to set the page geometry (height, width, margins, footer, header, page background) for ODT output, you need to define it in a separate file holding all the styles you want to use, my-reference.odt.

Then, when generating ODT, use the --reference-odt=my-reference.odt command line switch for Pandoc.
​

On Sat, Aug 1, 2015 at 8:29 PM, Hi-Angel notifications@github.com wrote:

Setting page margins with geometry silently ignored upon being converted
to an .odt. A minimal reproducible testcase:

\documentclass{article}
\usepackage[top=1cm, bottom=1.25cm, left=4cm, right=1.25cm]{geometry}

\begin{document}

\section{First Section}

\end{document}

Here the left margin being set the giant 4cm — however it upon converted
to .odt the left margin becomes set to zero.

The command to convert is pandoc -f latex -t odt -o output.odt test.tex

Pandoc version is 1.15.0.6

—
Reply to this email directly or view it on GitHub
#2340.

[Hi-Angel]

@KurtPfeifle do you mean configuring the styles by hand? Hm… You know, it is a good idea — if this is indeed possible, I think I could try to write my diploma in Markdown, and configure styles with a separate «.odt»…

Anyway, the problem is remains. I can say even more: in different times I tried to convert different formats, and the pandoc have never ever worked for me; in the end I always used another converter. Today I wanted to try to fix a few, then I found that with regard to a LaTeX there still a bunch of problem, I just won't have a time for all of them; plus after I saw one pull request that referred to a feature I need I'm not even sure these would be accepted. Still I have a feeling that I shouldn't leave it as is, and I must at least start reporting them.

[KurtPfeifle]

On Sat, Aug 1, 2015 at 8:55 PM, Hi-Angel notifications@github.com wrote:

@KurtPfeifle https://github.com/KurtPfeifle do you mean configuring the

styles by hand? Hm… You know, it is a good idea — if this is indeed
possible, I think I could try to write my diploma in Markdown, and
configure styles with a separate «.odt»…

You can style other things this way as well of course. Like font styles and
sizes, etc.

Anyway, the problem is remains. I can say even more: in different times I

tried to convert different formats, and the pandoc have never ever worked
for me; in the end I always used another converter.

This statement says to me only this: You started to use Pandoc without
having had a good look at the available documentation. (If you had had
that, you’d be aware of the --reference-odt=... and --reference-docx=... as
well…)

My advice to you is to read the available documentation
http://pandoc.org/README.html as a next step to become more familiar
with Pandoc.

​

[Hi-Angel]

@KurtPfeifle I am not sure I understand you. I am thankful to you for the hint in general, but it have little to do with the fact that pandoc ignores elements of a particular format, like geometry here.

[KurtPfeifle]

Pandoc is able to handle a lot of very different document formats.

However, it is impossible to transform the specific _layout_ of one document format into an (identical) layout of a different document format.

What _is_ possible (even not completely), is to transform + preserve the document _structures_. And this is what Pandoc does, and does really well.

geometry is a very LaTeX specific class of settings. It _may_ be possible to extract the major geometry parameters with the help of a specific (not-yet-written, AFAIK) third-party Pandoc filter and somehow fiddle it into the ODT output.

If you read up more about Pandoc's capabilities, scope and also stuff that's known to not work you will become more aware of these issues and can adapt your expectations to reality.

[KurtPfeifle]

(Note about my previous answers: the formatting of these is b0rken. I had replied to them by eMail, and had put Markdown formatting inside. It seems that I shouldn't do that -- the Markdown formatting does not arrive in the same shape on this website.

It is even impossible to edit the comment here on the website and fix its formatting. While it will look OK in the Preview tab, it will be even worse than before in the real view. 👎

_Note to self:_ I should always go to the GitHub website to reply to posts if I want to be sure my formatting is OK.)

[Hi-Angel]

@KurtPfeifle ☺

What is called geometry here are simply margins in odt, doc, rtf, and css (not sure if pandoc can do the latest, but anyway). That aren't few formats. And I don't see anything specific to LaTeX in this, and even a single reason why this layout could be hard to convert into another format. If you want it, I could even find the exact xml element to be changed to convert it to .odt.

More over, I recall that CSS even support a bunch of different units, like cm, in, et cetera. I think even if office formats doesn't, it is easy to convert it to an according supported measure unit, perhaps with rounding.

[jgm]

+++ Hi-Angel [Aug 01 15 11:55 ]:

Anyway, the problem is remains. I can say even more: in different times
I tried to convert different formats, and the pandoc have never ever
worked for me; in the end I always used another converter. Today I
wanted to try to fix a few, then I found that with regard to a LaTeX
there still a bunch of problem, I just won't have a time for all of
them; plus after I saw [2]one pull request that referred to a feature I
need I'm not even sure these would be accepted. Still I have a feeling
that I shouldn't leave it as is, and I must at least start reporting
them.

Pandoc identifies structural elements in a document and
tries to convert them. Everything goes through a structural
representation of the document that is strictly less
expressive than formats like HTML or OpenDocument -- that's
what makes it possible to do the MxN conversions. Lots of
little formatting details will not come across.

To see what is "in scope," you can have a look at the Pandoc
data structure (pandoc's representation of a document).
https://hackage.haskell.org/package/pandoc-types-1.12.4.5/docs/Text-Pandoc-Definition.html

Features not representable there won't come across in
conversions (you won't find a representation of page
margins, for example), and you shouldn't submit bug reports
that point this out. It's explicit in the documentation
that support for formats other than pandoc's Markdown is
incomplete.

[Hi-Angel]

@jgm I saw the module today, while I tried to fix a page counter. What I am see — is that we just need to add to the data elements according to a page, and etc. Obviously when one want to convert into a format that doesn't support pages, that would be simply ignored. But why should we do it for those formats that have that support?

[Hi-Angel]

Ah, I see your answer to another issue. Okay, now it is more clear. So, to sum up — if one wants to add a new element into the Pandoc ADT, they have to do pull request with it being also implemented in every reader and writer, right?

[jgm]

+++ Hi-Angel [Aug 01 15 14:23 ]:

Ah, [1]I see your answer to another issue. Okay, now it is more clear.
So, to sum up — if one wants to add an new element into the Pandoc ADT,
they have to do pull request with it being also implemented in every
reader and writer, right?

Yes. But also there should be preliminary discussion on
pandoc-discuss, about whether the feature should be added
and how. (See the CONTRIBUTING document.)

[Hi-Angel]

@jgm why did you close it? The fact that it's hard to add doesn't magically make the bug nonexisting :/

[jgm]

+++ Hi-Angel [Aug 07 15 23:52 ]:

[1]@jgm why did you close it? The fact that it's hard to add doesn't
magically make the bug nonexisting :/

Because it's not a bug, but "out of scope." As I explained,
pandoc seeks to extract document structure, not all details
of formatting. You need to set the margins in your output
template or reference.docx/odt, as detailed above.

[Hi-Angel]

@jgm oh, well, then it would be nice to see at the main page that support of margins is "out of scope".

To be clear: supposedly that e.g. docx and latex had the same formatting features, then the convertation "docx→latex→docx" should be identity. When it isn't, the converter is buggy.

I think adding to the main and "Contributing" pages all the things "out of scope" would save much time for both people trying to use the app, and the ones who reporting or fixing the "out of scope" bugs.

[jgm]

Good idea, I've done this in
f78b5a4

+++ Hi-Angel [Aug 08 15 14:19 ]:

[1]@jgm oh, well, then it would be nice to see at the main page that
support of margins is "out of scope".

To be clear: supposedly that e.g. docx and latex had the same
formatting features, then the convertation "docx→latex→docx" should be
identity. When it isn't, the converter is buggy.

I think adding to the main and "Contributing" page all the things "out
of scope" would save much time for both people trying to use the app,
and the ones who reporting or fixing the "out of scope" bugs.

—
Reply to this email directly or [2]view it on GitHub.

References

1. https://github.com/jgm
2. Setting margins with «geometry» in LaTeX doesn't work #2340 (comment)