emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* Proposal for images in markdown export (ox-md)
@ 2014-02-10  0:21 John Hendy
  2014-02-10  9:07 ` Bastien
  0 siblings, 1 reply; 4+ messages in thread
From: John Hendy @ 2014-02-10  0:21 UTC (permalink / raw)
  To: emacs-orgmode

Hi,


I've been playing around with the ox-md lately and wondered about the
idea of shifting the exported image syntax if any html options are
present. While the markdown file could be changed prior to re-export
to something else, it would seem that specifying options in Org might
imply they want might want those options applied to the markdown file
as well.

Or I'm perhaps wrong about this given the aim of markdown, but in that
case I'd at least propose a change to the current behavior of
#+begin/end_center.

The current behavior is such that no image attributes can be specified
(that I've found), which sort of makes sense given that markdown
doesn't have any image tweaking syntax. If you google around on how to
do this, the answer is simply to use straight <img ... > html instead
of the typical ![description](/path/to/image.png) format.

So, my proposal would be that if either are present, Org could
(should?) use html image specifications instead of markdown.

2) Behavior with centering:

- org

#+begin_center
[[./img.png]]
#+end_center

- exported to markdown (doesn't work when converting to .html)

<div class="center">
![nil](./img.png)
</div>

2) attributes

- org

#+attr_html: :style display: block; margin-left: auto; margin-right:
auto; height: 400px
[[./img.png]]

- markdown

![nil](./img.png)

The second works in that the image is displayed as-is from the file.
For conversion from .md to something else, this only works if the
image is the exact size required for the resultant document. I'd
prefer not to have to resize every image I want to use in a markdown
document just for that markdown document.

I'm a bit confused about the <div> behavior, as I've encountered at
least one suggestion that this should work, but at least with knitr
and knit2html, this doesn't render properly (it just prints the
verbatim text, "![nil](./img.png)").
- http://stackoverflow.com/a/1228126/495990

Is there a reason Org uses this for #+begin_center?

The documentation says that the html backend behavior will be used
where ox-md doesn't have support, and the html behavior for
#+begin/end_center is to export an image like so:

<div class="figure"><p><img ... /></div>

There's corresponding css in the header for the figure class:

.figure { padding: 1em; }
.figure p { text-align: center; }

Based, on this, one *might* make the case that ox-html should take
over when attributes are specified. Just one thought process :)


Thanks for any feedback,
John

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Proposal for images in markdown export (ox-md)
  2014-02-10  0:21 Proposal for images in markdown export (ox-md) John Hendy
@ 2014-02-10  9:07 ` Bastien
  2014-02-10 16:43   ` Nicolas Goaziou
  0 siblings, 1 reply; 4+ messages in thread
From: Bastien @ 2014-02-10  9:07 UTC (permalink / raw)
  To: John Hendy; +Cc: emacs-orgmode

[-- Attachment #1: Type: text/plain, Size: 396 bytes --]

Hi John,

John Hendy <jw.hendy@gmail.com> writes:

> So, my proposal would be that if either are present, Org could
> (should?) use html image specifications instead of markdown.

I'll let Nicolas decide on this.

In the meantime, I find the attached patch useful.

It uses the file-name instead of [img] when the image link has no
description.

If you find this useful, I'll apply it.

Thanks,


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: ox-md-fix-img-name.patch --]
[-- Type: text/x-diff, Size: 494 bytes --]

diff --git a/lisp/ox-md.el b/lisp/ox-md.el
index 76bea94..26a36e2 100644
--- a/lisp/ox-md.el
+++ b/lisp/ox-md.el
@@ -306,7 +306,8 @@ a communication channel."
 		 (caption (org-export-data
 			   (org-export-get-caption
 			    (org-export-get-parent-element link)) info)))
-	     (format "![img](%s)"
+	     (format "![%s](%s)"
+		     (file-name-nondirectory path)
 		     (if (not (org-string-nw-p caption)) path
 		       (format "%s \"%s\"" path caption)))))
 	  ((string= type "coderef")

[-- Attachment #3: Type: text/plain, Size: 14 bytes --]


-- 
 Bastien

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: Proposal for images in markdown export (ox-md)
  2014-02-10  9:07 ` Bastien
@ 2014-02-10 16:43   ` Nicolas Goaziou
  2014-02-10 17:03     ` John Hendy
  0 siblings, 1 reply; 4+ messages in thread
From: Nicolas Goaziou @ 2014-02-10 16:43 UTC (permalink / raw)
  To: Bastien; +Cc: emacs-orgmode

Hello,

Bastien <bzg@gnu.org> writes:

>> So, my proposal would be that if either are present, Org could
>> (should?) use html image specifications instead of markdown.
>
> I'll let Nicolas decide on this.

FWIW, I think it makes sense to switch to HTML when attributes are
given. Though, I don't use Markdown, so I may overlook something.


Regards,

-- 
Nicolas Goaziou

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Proposal for images in markdown export (ox-md)
  2014-02-10 16:43   ` Nicolas Goaziou
@ 2014-02-10 17:03     ` John Hendy
  0 siblings, 0 replies; 4+ messages in thread
From: John Hendy @ 2014-02-10 17:03 UTC (permalink / raw)
  To: Nicolas Goaziou; +Cc: Bastien, emacs-orgmode

On Mon, Feb 10, 2014 at 10:43 AM, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
> Hello,
>
> Bastien <bzg@gnu.org> writes:
>
>>> So, my proposal would be that if either are present, Org could
>>> (should?) use html image specifications instead of markdown.
>>
>> I'll let Nicolas decide on this.
>
> FWIW, I think it makes sense to switch to HTML when attributes are
> given. Though, I don't use Markdown, so I may overlook something.

As I was thinking more about this (of course, right after sending),
I'm not sure it's the best idea, since markdown is like org: one
syntax that can flexibly be exported into numerous other formats.
Thus, I realized that for *me*, I'll either use Org -> LaTeX or Org ->
md -> html (via ox-ravel, knitr, or pandoc), but probaly *not* Org ->
md -> LaTeX (via knitr or pandoc).

Others, however, might want Org -> md -> LaTeX, so assuming that html
image tags are desired might be the wrong assumption and cause issues.
Perhaps a variable would be the way to go? This way, one could have
something like org-md-final-format (you get the idea) that could
provide different results:

- (setq org-md-final-format nil): ignores everything, including
#+begin/end_center and just outputs
=![description](path/to/image.png)=

- (setq org-md-final-format "html"): converts attr_html or attr_md and
#+begin/end_center to either inline styles with <img style="..."
src="path/to/img.png" />, or surrounds with a classed div tag and does
the appropriate styling via CSS (similar to current html export with
img.figure { ...style... }

- (setq org-md-final-format "latex"): converts attr_latex and
centering straight to LaTeX code. I have caution on this one as I
haven't actually looked into how knitr or pandoc work with md -> latex
and if it accepts raw LaTeX. I'm figuring it does, but just wanted to
mention that.

So, that would be one idea of how to deal with this. I'd love for
other markdown users to comment, as I'm not really sure how it's used
by the majority.



John

>
>
> Regards,
>
> --
> Nicolas Goaziou

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2014-02-10 17:04 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-02-10  0:21 Proposal for images in markdown export (ox-md) John Hendy
2014-02-10  9:07 ` Bastien
2014-02-10 16:43   ` Nicolas Goaziou
2014-02-10 17:03     ` John Hendy

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).