-
-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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
Implement ODT support for implicit_figures #2401
Comments
No timeline. If someone wants to write the code (and adjust tests accordingly) and submit a PR, I'd certainly consider merging it. |
Thanks for the info! |
If you want to reopen this, the code sample you pasted in +++ Ian [Sep 17 15 00:10 ]:
|
OK, wish I could help but I really wouldn't know where to start, plus Haskell looks like Klingon to my poor Biologist-procedural-programmer eyes. I had a look at the Text.Pandoc.Writers.ODT.hs and see there is a blockToOpenDocument function but how to wrangle that to do the conversion... Thanks John! |
This will probably look more straightforward (and this is https://github.com/jgm/pandoc/blob/master/src/Text/Pandoc/Writers/OpenDocument.hs See line 347, definition of 'figure'. +++ Ian [Sep 17 15 12:06 ]:
|
Also this is the code in MMD that handles images with optional captions: https://github.com/fletcher/MultiMarkdown-4/blob/master/odf.c#L463 |
I guess docs should've been updated, but other than that, I believe Pandoc supports |
@lierdakil — hm, going from MMD -> ODT with the example above and no image captions are generated. Perhaps this fails for the MMD input case, though the syntax is the same I think. If I use:
I get no caption even as a subsequent paragraph: <text:p text:style-name="First_20_paragraph"><draw:frame draw:name="img1" svg:width="397pt" svg:height="400pt"><draw:image xlink:href="Pictures/0.png" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad" /></draw:frame></text:p> using the following commandline: |
Right, if I omit the MMD |
Try explicitly enabling:
|
Yes, that works @lierdakil thank you. So the question is if there is a reason the extension is not enabled by default for MMD (as both support the same syntax for the same feature), if there is then this can be closed. MMD also wraps the figure caption in a frame which is slightly cleaner structurally, and appends figure number sequence (auto numbering which a reference-able). The XML seems pretty straight-forward for this. No great issue and I could probably even hack this myself, but wonder if there are reasons against using a frame (1) and adding numbering (2). The argument against (2) is that it wouldn't apply across output formats (does HTML even support auto-numbering etc.). But wrapping the caption in a frame is what LibreOffice does by default I think. |
Automatic numbering is not something we can replicate in other output As for frame, I briefly considered implementing it, but XML happened to be
|
So, @jgm, do you suppose we could add |
Thanks @lierdakil, using a frame is no big issue. And I understand the issue with auto-numbering, though pandoc does have other features only some formats support but not others. But that is for another issue. I also notice |
+++ Ian [Oct 01 15 16:30 ]:
It may be that some features were added to MMD since I added the |
Here is the documentation FYI for http://fletcher.github.io/MultiMarkdown-4/MMD_Users_Guide.html#superscriptsandsubscripts |
Subscripts and superscripts work differently in MMD. |
@iandol I think the numbering is a bit problematic, without some mechanism for localization -- we don't want to bake in the word "Figure" as the XML above does. But putting the whole thing in a frame seems worth doing and shouldn't be too complex. @lierdakil what difficulties did you encounter? I don't think we need to worry about other formats. It would be good to do this in Word too, but I see no reason not to do it in ODT even without doing it in Word. |
@jgm, it was a while ago, so details are somewhat fuzzy. What I can remember right off the bat is that frame dimensions were messed up between OO and LO due to different rendering strategy, and only way I was able to make it work in both was setting frame dimensions in pixels. I'm no ODF expert though, so I might have missed an obvious solution. P.S. And when I was talking about Word, I meant it's ODT renderer, not docx. |
Even with images as they currently are (without the nested frames) I often have to do manual resizing in odt (Libreoffice), so I don't think that should be a show stopper. @lierdakil - perhaps whatever code you wrote before is worth trying again in the latest releases of OO.org and LO, if you still have it. As for hardcoding "Figure", is there anything wrong with a writer-specific option? |
@hubertp-lshift, I believe #3165 is for ODT reader. This issue about ODT writer output, so no, probably not. |
This is a confusing thread. If I'm not mistaken, the only outstanding issue here is whether ODT figures can be put into a frame? |
@jgm I think it all boils down to nobody having all three of time, skill and interest to do it. ODT figures definitely can be put in frames, as I've used perl to post-process pandoc output to that effect in the past. |
@jgm: yes that is the only outstanding issue, which probably still applies also applies to DOCX as well as ODT unless something has changed (didn't see anything in the changelog). |
I'm looking at it. It should be doable. I assume the point is to limit the width of the caption to the width of the figure which is useful if you want to place it on the side of a page with text wrapping around it or similar? |
@jgm I've had a good look now. This isn't strictly speaking something I need right now, maybe later. This would be rather invasive. Basically we need to split dimension setting into two parts in the case where there is an outer and inner frame (the outer contains caption and figure, the inner one contains only the figure.) This is made complicated by the fact that we post-process dimensions in transformPicMath function in ODT.hs . This makes things awkward to say the least. Do you know why it's done this way? Maybe because this is where we actually push the image into the file and can therefore get the real dimensions? |
Nils Carlson <notifications@github.com> writes:
This is made complicated by the fact that we post-process dimensions in transformPicMath function in ODT.hs . This makes things awkward to say the least.
Do you know why it's done this way? Maybe because this is where we actually push the image into the file and can therefore get the real dimensions?
Originally the OpenDocument writer was pure -- could
not do IO, including looking at images -- and all the
IO operations were put into the ODT writer. Now that
we have the PandocMonad interface, we could do it
differently and read image dimensions in the
OpenDocument writer. If that would make it easier to
support proper frames for figures, I'd say it would
be worth it.
|
This would definitely make it easier. Also easier for anyone reading the code to figure out what's going on. I'll look at the other writers and see if I can figure out how this would work. |
This is old and I think not relevant anymore, time to close... |
Hi, the documentation suggests for implicit_figures "This feature is not yet implemented for RTF, OpenDocument, or ODT". Multimarkdown does support figure captions for block markup figures, with this MMD:
generating the following FODT:
Will implicit_figures for ODT be supported in pandoc at some point in the future, and is there a timeline more or less? Thanks for an excellent tool!
The text was updated successfully, but these errors were encountered: