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

Syntax for specifying image size #261

Closed
jgm opened this Issue Jun 10, 2011 · 117 comments

Comments

Projects
None yet
@jgm
Owner

jgm commented Jun 10, 2011

Googlecode Issue #29

There is currently no way to specify the size of an image.
For some ideas, see http://code.google.com/p/pandoc/wiki/ImageSizes.

@jgm

This comment has been minimized.

Show comment
Hide comment
@jgm

jgm Jun 10, 2011

Owner

Comment 2 by schm...@gmx.de, Nov 10, 2010
You can enter the dimensions of an image in the header of the JPG or PNG files. LaTeX and the DocBook processors will use that size. In HTML output you can set the size for every image in a separate CSS file.

Owner

jgm commented Jun 10, 2011

Comment 2 by schm...@gmx.de, Nov 10, 2010
You can enter the dimensions of an image in the header of the JPG or PNG files. LaTeX and the DocBook processors will use that size. In HTML output you can set the size for every image in a separate CSS file.

@candlerb

This comment has been minimized.

Show comment
Hide comment
@candlerb

candlerb Jul 19, 2011

Duplicate of #61 ?

Duplicate of #61 ?

@seanfarley

This comment has been minimized.

Show comment
Hide comment
@seanfarley

seanfarley Oct 15, 2012

I'd like to say for the record that all of the advice for image manipulation (see above) doesn't help at all when dealing with vector image formats (svg, TikZ, pdf, etc.). This issue is quite the wrench.

I'd like to say for the record that all of the advice for image manipulation (see above) doesn't help at all when dealing with vector image formats (svg, TikZ, pdf, etc.). This issue is quite the wrench.

@pckujawa

This comment has been minimized.

Show comment
Hide comment
@pckujawa

pckujawa Apr 22, 2013

@jgm mentions that

You can enter the dimensions of an image in the header of the JPG or PNG files.

I'm not sure what that means. Where does one specify the header of one of these image files? I assume this isn't in reference to the bytes of the image file itself.

@jgm mentions that

You can enter the dimensions of an image in the header of the JPG or PNG files.

I'm not sure what that means. Where does one specify the header of one of these image files? I assume this isn't in reference to the bytes of the image file itself.

@jgm

This comment has been minimized.

Show comment
Hide comment
@jgm

jgm Apr 22, 2013

Owner

+++ pckujawa [Apr 22 13 00:53 ]:

[1]@jgm mentions that

 You can enter the dimensions of an image in the header of the JPG or
 PNG files.

I'm not sure what that means. Where does one specify the header of one
of these image files? I assume this isn't in reference to the bytes of
the image file itself.

The DPI is stored in metadata in the header of the image files.
You can view and manipulate it with most image manipulation programs
(e.g. Gimp, Photoshop). I like to use ImageMagick command line tools,
myself.

convert -units PixelsPerInch my.jpg -density 300 my.new.jpg
Owner

jgm commented Apr 22, 2013

+++ pckujawa [Apr 22 13 00:53 ]:

[1]@jgm mentions that

 You can enter the dimensions of an image in the header of the JPG or
 PNG files.

I'm not sure what that means. Where does one specify the header of one
of these image files? I assume this isn't in reference to the bytes of
the image file itself.

The DPI is stored in metadata in the header of the image files.
You can view and manipulate it with most image manipulation programs
(e.g. Gimp, Photoshop). I like to use ImageMagick command line tools,
myself.

convert -units PixelsPerInch my.jpg -density 300 my.new.jpg
@pckujawa

This comment has been minimized.

Show comment
Hide comment
@pckujawa

pckujawa Apr 23, 2013

Ah, so you were referring to the bytes in the image file itself. That
method doesn't let me specify a width that is larger than, for example, the
\maxwidth of the latex page, but I guess that is by design (otherwise
things overflow badly).

For anyone else using latex, I did find that \includegraphics does not work
as expected because the default template has the following remapping:

$if(graphics)$
\usepackage{graphicx}
% We will generate all images so they have a width \maxwidth. This means
% that they will get their normal width if they fit onto the page, but
% are scaled down if they would overflow the margins.
\makeatletter
\def\maxwidth{\ifdim\Gin@nat@width>\linewidth\linewidth
\else\Gin@nat@width\fi}
\makeatother
\let\Oldincludegraphics\includegraphics
\renewcommand{\includegraphics}[1]{\Oldincludegraphics[width=\maxwidth]{#1}}
$endif$

So if you want to use latex and \includegraphics[width=...], you need to
comment out the \renewcommand. Just curious, is there no way to pass
arguments into the [] part of a macro in latex? If there is, why not allow
users to pass in their own [width=...] without having to edit the template?
I'm a newbie to latex macros, so maybe I just don't understand their
complexity.

Thanks for pandoc!
Pat

On Mon, Apr 22, 2013 at 9:43 AM, John MacFarlane - notifications@github.com
github.pck.374cd93cd6.notifications#github.com@ob.0sg.net wrote:

+++ pckujawa [Apr 22 13 00:53 ]:

[1]@jgm mentions that

You can enter the dimensions of an image in the header of the JPG or
PNG files.

I'm not sure what that means. Where does one specify the header of one
of these image files? I assume this isn't in reference to the bytes of
the image file itself.

The DPI is stored in metadata in the header of the image files.
You can view and manipulate it with most image manipulation programs
(e.g. Gimp, Photoshop). I like to use ImageMagick command line tools,
myself.

convert -units PixelsPerInch my.jpg -density 300 my.new.jpg


Reply to this email directly or view it on GitHubhttps://github.com/jgm/pandoc/issues/261#issuecomment-16795811
.

Ah, so you were referring to the bytes in the image file itself. That
method doesn't let me specify a width that is larger than, for example, the
\maxwidth of the latex page, but I guess that is by design (otherwise
things overflow badly).

For anyone else using latex, I did find that \includegraphics does not work
as expected because the default template has the following remapping:

$if(graphics)$
\usepackage{graphicx}
% We will generate all images so they have a width \maxwidth. This means
% that they will get their normal width if they fit onto the page, but
% are scaled down if they would overflow the margins.
\makeatletter
\def\maxwidth{\ifdim\Gin@nat@width>\linewidth\linewidth
\else\Gin@nat@width\fi}
\makeatother
\let\Oldincludegraphics\includegraphics
\renewcommand{\includegraphics}[1]{\Oldincludegraphics[width=\maxwidth]{#1}}
$endif$

So if you want to use latex and \includegraphics[width=...], you need to
comment out the \renewcommand. Just curious, is there no way to pass
arguments into the [] part of a macro in latex? If there is, why not allow
users to pass in their own [width=...] without having to edit the template?
I'm a newbie to latex macros, so maybe I just don't understand their
complexity.

Thanks for pandoc!
Pat

On Mon, Apr 22, 2013 at 9:43 AM, John MacFarlane - notifications@github.com
github.pck.374cd93cd6.notifications#github.com@ob.0sg.net wrote:

+++ pckujawa [Apr 22 13 00:53 ]:

[1]@jgm mentions that

You can enter the dimensions of an image in the header of the JPG or
PNG files.

I'm not sure what that means. Where does one specify the header of one
of these image files? I assume this isn't in reference to the bytes of
the image file itself.

The DPI is stored in metadata in the header of the image files.
You can view and manipulate it with most image manipulation programs
(e.g. Gimp, Photoshop). I like to use ImageMagick command line tools,
myself.

convert -units PixelsPerInch my.jpg -density 300 my.new.jpg


Reply to this email directly or view it on GitHubhttps://github.com/jgm/pandoc/issues/261#issuecomment-16795811
.

@adityam

This comment has been minimized.

Show comment
Hide comment
@adityam

adityam Apr 24, 2013

Contributor

From what I understand, there is no consensus on markdown syntax to specify the width of an image. For that reason, width specifications are not supported.

Contributor

adityam commented Apr 24, 2013

From what I understand, there is no consensus on markdown syntax to specify the width of an image. For that reason, width specifications are not supported.

@adityam

This comment has been minimized.

Show comment
Hide comment
@adityam

adityam Apr 24, 2013

Contributor

Similar to HTML+CSS, ConTeXt allows you to specify the dimensions of individual figures. You can create a figures.tex file:

\defineexternalfigure[filename.ext][width=..., height=...]
\defineexternalfigure[filename.ext][width=..., height=...]

Then generate a ConTeXt file using

pandoc -t context -s output.tex

and compile it using

context --environment=figures.tex output.tex
Contributor

adityam commented Apr 24, 2013

Similar to HTML+CSS, ConTeXt allows you to specify the dimensions of individual figures. You can create a figures.tex file:

\defineexternalfigure[filename.ext][width=..., height=...]
\defineexternalfigure[filename.ext][width=..., height=...]

Then generate a ConTeXt file using

pandoc -t context -s output.tex

and compile it using

context --environment=figures.tex output.tex
@pckujawa

This comment has been minimized.

Show comment
Hide comment
@pckujawa

pckujawa Jun 11, 2013

@adityam Thanks, good to know.

@adityam Thanks, good to know.

@nichtich

This comment has been minimized.

Show comment
Hide comment
@nichtich

nichtich Jun 13, 2013

Contributor

Just a note: if image size should be specified in Pandoc Markdown, one must be able to specify at least two kinds of sizes: first the size in cm or inch for PDF, DocBook, Word etc. and second the size in pixels for HTML, EPUB and related output formats. For bitmap image files both can also be specified in the image files but vector image files usually contain no pixel dimensions.

Contributor

nichtich commented Jun 13, 2013

Just a note: if image size should be specified in Pandoc Markdown, one must be able to specify at least two kinds of sizes: first the size in cm or inch for PDF, DocBook, Word etc. and second the size in pixels for HTML, EPUB and related output formats. For bitmap image files both can also be specified in the image files but vector image files usually contain no pixel dimensions.

@mb21

This comment has been minimized.

Show comment
Hide comment
@mb21

mb21 Jul 22, 2013

Collaborator

A TeX hack to get floating images in ConTeXt is to redifine \externalfigure:

\let\externalfigureOrig\externalfigure
\def\externalfigure[#1]{\placefigure[right]{}{\externalfigureOrig[#1]}}
Collaborator

mb21 commented Jul 22, 2013

A TeX hack to get floating images in ConTeXt is to redifine \externalfigure:

\let\externalfigureOrig\externalfigure
\def\externalfigure[#1]{\placefigure[right]{}{\externalfigureOrig[#1]}}
@adityam

This comment has been minimized.

Show comment
Hide comment
@adityam

adityam Jul 22, 2013

Contributor

This issue is about changing figure size, and not its floating behavior. By default,

 $pandoc -t context 
 ![Caption](cow.pdf)

gives

\placefigure[here,nonumber]{Caption}{\externalfigure[cow.pdf]}

Do you want to change the floating behavior (from here which floats only when necessary) to right? If so, a better way might be to modify pandoc to generate

\placefigure{Caption}{\externalfigure[cow.pdf]}

and set the default floating behaviour using \setupfloat[figure][location={....}].

Contributor

adityam commented Jul 22, 2013

This issue is about changing figure size, and not its floating behavior. By default,

 $pandoc -t context 
 ![Caption](cow.pdf)

gives

\placefigure[here,nonumber]{Caption}{\externalfigure[cow.pdf]}

Do you want to change the floating behavior (from here which floats only when necessary) to right? If so, a better way might be to modify pandoc to generate

\placefigure{Caption}{\externalfigure[cow.pdf]}

and set the default floating behaviour using \setupfloat[figure][location={....}].

@jgm

This comment has been minimized.

Show comment
Hide comment
@jgm

jgm Oct 21, 2013

Owner

I just discovered that in HTML you can do

<img style="width: 3cm;"...>

This resolves the problem about how to convert between pixels and other measurements; we'll just let the browser handle that.

Owner

jgm commented Oct 21, 2013

I just discovered that in HTML you can do

<img style="width: 3cm;"...>

This resolves the problem about how to convert between pixels and other measurements; we'll just let the browser handle that.

@timtylin

This comment has been minimized.

Show comment
Hide comment
@timtylin

timtylin Oct 21, 2013

Contributor

Note that in almost all browsers, 1 in (and equivalently 2.54 cm) is simply shorthand for 96 pixels.

Contributor

timtylin commented Oct 21, 2013

Note that in almost all browsers, 1 in (and equivalently 2.54 cm) is simply shorthand for 96 pixels.

@jgm

This comment has been minimized.

Show comment
Hide comment
@jgm

jgm Oct 21, 2013

Owner

Here is what multimarkdown does:

[image]: http://path.to/image "Image title" width=400px height=400px
[link]:  http://path.to/link.html "Some Link" class=external
     style="border: solid black 1px;"

I like the basic idea. I'd like to allow something similar in inline images and links:

![image](http://path.to/image "Image title" width=4cm)
[link](http://path.to/link.html "some link" class=external)

Some questions and potential difficulties:

  1. What units to allow? cm, em, and in will work for both LaTeX and HTML (using styles). px is more problematic.
  2. There is some argument for reusing the existing attribute syntax (used now in headers and code blocks) for consistency. That would suggest something like
[image]: http://path.to/image "Image title" {width=400px height=400px}
[link]:  http://path.to/link.html "some link" {.external style="border: solid black 1 px;"}

and in inline form,

![image](http://path.to/image "title" {width=400px height=400px})

or should it be

![image](http://path.to/image "title"){width=400px height=400px}
  1. Another advantage of the curly-bracket form is that it avoids some parsing difficulties, especially when no title is present. Currently spaces are allowed in the URL part of a markdown link, so
[link](http://path.to/link.html class=external)

would be parsed as a link to the URL http://path.to/link.html%20class=external, and the multimarkdown format would break this existing behavior. Requiring curly brackets for attributes gives the parser a clear signal.

Owner

jgm commented Oct 21, 2013

Here is what multimarkdown does:

[image]: http://path.to/image "Image title" width=400px height=400px
[link]:  http://path.to/link.html "Some Link" class=external
     style="border: solid black 1px;"

I like the basic idea. I'd like to allow something similar in inline images and links:

![image](http://path.to/image "Image title" width=4cm)
[link](http://path.to/link.html "some link" class=external)

Some questions and potential difficulties:

  1. What units to allow? cm, em, and in will work for both LaTeX and HTML (using styles). px is more problematic.
  2. There is some argument for reusing the existing attribute syntax (used now in headers and code blocks) for consistency. That would suggest something like
[image]: http://path.to/image "Image title" {width=400px height=400px}
[link]:  http://path.to/link.html "some link" {.external style="border: solid black 1 px;"}

and in inline form,

![image](http://path.to/image "title" {width=400px height=400px})

or should it be

![image](http://path.to/image "title"){width=400px height=400px}
  1. Another advantage of the curly-bracket form is that it avoids some parsing difficulties, especially when no title is present. Currently spaces are allowed in the URL part of a markdown link, so
[link](http://path.to/link.html class=external)

would be parsed as a link to the URL http://path.to/link.html%20class=external, and the multimarkdown format would break this existing behavior. Requiring curly brackets for attributes gives the parser a clear signal.

@jgm

This comment has been minimized.

Show comment
Hide comment
@jgm

jgm Oct 21, 2013

Owner

Is this hard coded in the browsers, or is it sensitive to the system
DPI setting?

On linux, at least, you can change the system DPI:
https://wiki.archlinux.org/index.php/Xorg#Setting_DPI_manually

+++ Tim Lin [Oct 21 13 13:05 ]:

Note that in almost all browsers, 1 in (and equivalently 2.54 cm) is
simply shorthand for [1]96 pixels.


Reply to this email directly or [2]view it on GitHub.
[xJAuenYDiIoVt3LF3y6848lkNPgY-QGjRmh7vcZK4inXnxdKsKiEjkMtMuE82YEe.gif]

References

  1. http://www.quirksmode.org/blog/archives/2012/11/the_css_physica.html
  2. #261 (comment)
Owner

jgm commented Oct 21, 2013

Is this hard coded in the browsers, or is it sensitive to the system
DPI setting?

On linux, at least, you can change the system DPI:
https://wiki.archlinux.org/index.php/Xorg#Setting_DPI_manually

+++ Tim Lin [Oct 21 13 13:05 ]:

Note that in almost all browsers, 1 in (and equivalently 2.54 cm) is
simply shorthand for [1]96 pixels.


Reply to this email directly or [2]view it on GitHub.
[xJAuenYDiIoVt3LF3y6848lkNPgY-QGjRmh7vcZK4inXnxdKsKiEjkMtMuE82YEe.gif]

References

  1. http://www.quirksmode.org/blog/archives/2012/11/the_css_physica.html
  2. #261 (comment)
@mb21

This comment has been minimized.

Show comment
Hide comment
@mb21

mb21 Oct 21, 2013

Collaborator

I'm all for

![image](http://path.to/image "title"){width=400px height=400px class=myClass}

So we have each type of bracket besides the others [...](...){...} instead of [...](...{...}...). Also we're free to add additional attributes.

Collaborator

mb21 commented Oct 21, 2013

I'm all for

![image](http://path.to/image "title"){width=400px height=400px class=myClass}

So we have each type of bracket besides the others [...](...){...} instead of [...](...{...}...). Also we're free to add additional attributes.

@ambs

This comment has been minimized.

Show comment
Hide comment
@ambs

ambs Oct 21, 2013

👍 for [...](...){...}

ambs commented Oct 21, 2013

👍 for [...](...){...}

@timtylin

This comment has been minimized.

Show comment
Hide comment
@timtylin

timtylin Oct 21, 2013

Contributor

@jgm: As far as I can tell, this convention is part of the official CSS specification and does not obey variations in OS or device. I think there's currently no reliable method to have perfect physical sizing control short of probing for the actual physical device, and I'm not sure ultimately how useful it is anyways.

IMO one of the best practices is to use widths relative to the container. In LaTeX I've always used something like width=0.5\textwidth and in HTML that corresponds to width=50% (defaults to be relative to container width). I don't have any idea whether the other formats support this kind of thing, but it would make the most sense to me.

Contributor

timtylin commented Oct 21, 2013

@jgm: As far as I can tell, this convention is part of the official CSS specification and does not obey variations in OS or device. I think there's currently no reliable method to have perfect physical sizing control short of probing for the actual physical device, and I'm not sure ultimately how useful it is anyways.

IMO one of the best practices is to use widths relative to the container. In LaTeX I've always used something like width=0.5\textwidth and in HTML that corresponds to width=50% (defaults to be relative to container width). I don't have any idea whether the other formats support this kind of thing, but it would make the most sense to me.

@ambs

This comment has been minimized.

Show comment
Hide comment
@ambs

ambs Oct 21, 2013

I kind of agree with @evitaerc. I do that always, too, for LaTeX. But although LaTeX has a fixed page width, that is not true for HTML. But we can always support both (relative or absolute).

ambs commented Oct 21, 2013

I kind of agree with @evitaerc. I do that always, too, for LaTeX. But although LaTeX has a fixed page width, that is not true for HTML. But we can always support both (relative or absolute).

@nichtich

This comment has been minimized.

Show comment
Hide comment
@nichtich

nichtich Oct 21, 2013

Contributor

@mb21 and @ambs: So how would you expect to specify the size of an image for both, LaTeX/PDF and HTML/EPUB format? The original image will unlikely have 96 DPI. This would not work, would it?:

![image](http://path.to/image "title"){width=400px height=400px width=5cm height=5cm}

Its usual to create PDF and HTML from the same Markdown source. If the proposed syntax cannot support both of them at the same time, one must manually change the image file as it is needed now. A possible solution with limited usability is to support a "dpi" parameter. For instance 5cm / 203DPI = 400px:

![image](http://path.to/image "title"){width=400px height=400px dpi=203}
![image](http://path.to/image "title"){width=5cm height=5cm dpi=203}
Contributor

nichtich commented Oct 21, 2013

@mb21 and @ambs: So how would you expect to specify the size of an image for both, LaTeX/PDF and HTML/EPUB format? The original image will unlikely have 96 DPI. This would not work, would it?:

![image](http://path.to/image "title"){width=400px height=400px width=5cm height=5cm}

Its usual to create PDF and HTML from the same Markdown source. If the proposed syntax cannot support both of them at the same time, one must manually change the image file as it is needed now. A possible solution with limited usability is to support a "dpi" parameter. For instance 5cm / 203DPI = 400px:

![image](http://path.to/image "title"){width=400px height=400px dpi=203}
![image](http://path.to/image "title"){width=5cm height=5cm dpi=203}
@timtylin

This comment has been minimized.

Show comment
Hide comment
@timtylin

timtylin Oct 21, 2013

Contributor

@ambs: HTML at least has the container width that you can almost always count on. Having a width relative to the container width is also ideologically closer to the current almost de-facto system of rendering on a column/grid system for CSS (think of percentages like laying out a picture across 100 columns).

On the other hand, absolute sizes like pixels will test your resolve to live when you want to make it work for high-DPI handheld devices and 4K desktop displays.

Contributor

timtylin commented Oct 21, 2013

@ambs: HTML at least has the container width that you can almost always count on. Having a width relative to the container width is also ideologically closer to the current almost de-facto system of rendering on a column/grid system for CSS (think of percentages like laying out a picture across 100 columns).

On the other hand, absolute sizes like pixels will test your resolve to live when you want to make it work for high-DPI handheld devices and 4K desktop displays.

@dashed

This comment has been minimized.

Show comment
Hide comment
@dashed

dashed Oct 21, 2013

I like @nichtich's suggestion to have separate dimension specification for HTML and LaTeX (pdf output). You do not want to fixate pixel to an actual physical measurement. This is in my opinion the best way to go.

Other than the default case:

![image](path/to/image "title")

One may optionally include dimensions for either HTML or LaTeX:

  1. ![image](/path/to/image "title"){width=400px height=400px}
  2. ![image](path/to/image "title"){rwidth=5cm rheight=5cm}
  3. ![image](path/to/image "title"){width=400px height=400px rwidth=5cm rheight=5cm}

rheight and rwidth may refer to 'real' height and width for physical outputs.

If either dimensions for HTMl and LaTeX are excluded, then they're assumed to be default and handled by the browser or LaTeX pdf compiler accordingly.

Other cases may include that, if you only include rheight or rwidth, the aspect ratio is kept. I think this is the default behaviour in LaTeX without having to specify keepaspectratio.

How do we separate attributes for either LaTeX and HTML?

For instance,
![image](path/to/image "title"){width=400px, height=400px, rwidth=5cm, rheight=5cm, style="border:5px solid red;", class="imagestyle", angle=180}

Does anyone know if LaTeX throws an error if you just dump the attributes into:
\includegraphics[dump_attributes_here]{path/to/image}

dashed commented Oct 21, 2013

I like @nichtich's suggestion to have separate dimension specification for HTML and LaTeX (pdf output). You do not want to fixate pixel to an actual physical measurement. This is in my opinion the best way to go.

Other than the default case:

![image](path/to/image "title")

One may optionally include dimensions for either HTML or LaTeX:

  1. ![image](/path/to/image "title"){width=400px height=400px}
  2. ![image](path/to/image "title"){rwidth=5cm rheight=5cm}
  3. ![image](path/to/image "title"){width=400px height=400px rwidth=5cm rheight=5cm}

rheight and rwidth may refer to 'real' height and width for physical outputs.

If either dimensions for HTMl and LaTeX are excluded, then they're assumed to be default and handled by the browser or LaTeX pdf compiler accordingly.

Other cases may include that, if you only include rheight or rwidth, the aspect ratio is kept. I think this is the default behaviour in LaTeX without having to specify keepaspectratio.

How do we separate attributes for either LaTeX and HTML?

For instance,
![image](path/to/image "title"){width=400px, height=400px, rwidth=5cm, rheight=5cm, style="border:5px solid red;", class="imagestyle", angle=180}

Does anyone know if LaTeX throws an error if you just dump the attributes into:
\includegraphics[dump_attributes_here]{path/to/image}

@jgm

This comment has been minimized.

Show comment
Hide comment
@jgm

jgm Oct 21, 2013

Owner

I don't see the need for the complexity of separate measures for
different formats, if specifications like "50%" or "5cm" will work
for both. We can just disallow px measurements, or discourage them.

Owner

jgm commented Oct 21, 2013

I don't see the need for the complexity of separate measures for
different formats, if specifications like "50%" or "5cm" will work
for both. We can just disallow px measurements, or discourage them.

@uvtc

This comment has been minimized.

Show comment
Hide comment
@uvtc

uvtc Oct 22, 2013

![...](...){...} would mesh nicely with:

  • the fenced code block attribute syntax: ~~~{#my-code .haskell} ...
  • header attribute syntax: ## Section {#some-id}
  • the sometimes-proposed span syntax like [...]{...}
  • the sometimes-proposed fenced div syntax, possibly like ^^^{#some-id .some-class}...

uvtc commented Oct 22, 2013

![...](...){...} would mesh nicely with:

  • the fenced code block attribute syntax: ~~~{#my-code .haskell} ...
  • header attribute syntax: ## Section {#some-id}
  • the sometimes-proposed span syntax like [...]{...}
  • the sometimes-proposed fenced div syntax, possibly like ^^^{#some-id .some-class}...
@uvtc

This comment has been minimized.

Show comment
Hide comment
@uvtc

uvtc Oct 22, 2013

Added my comment about the div syntax (mentioned in prev comment here) to the end of issue #168.

uvtc commented Oct 22, 2013

Added my comment about the div syntax (mentioned in prev comment here) to the end of issue #168.

@dashed

This comment has been minimized.

Show comment
Hide comment
@dashed

dashed Oct 22, 2013

@jgm If that's the case, would you at least allow the style attribute for HTML? That way, style="height=40px;width=25px;" becomes an alternative for those who want to specify the height and width using px.

dashed commented Oct 22, 2013

@jgm If that's the case, would you at least allow the style attribute for HTML? That way, style="height=40px;width=25px;" becomes an alternative for those who want to specify the height and width using px.

@mb21

This comment has been minimized.

Show comment
Hide comment
@mb21

mb21 Oct 22, 2013

Collaborator

Personally, I usually want to use a width for TeX, and assign a class for HTML (so I can set width, floating and responsive design properties with CSS). I don't want to use percentages of the parent because scaling images in browsers by anything other than multiples of two usually produces aliasing artifacts.

Collaborator

mb21 commented Oct 22, 2013

Personally, I usually want to use a width for TeX, and assign a class for HTML (so I can set width, floating and responsive design properties with CSS). I don't want to use percentages of the parent because scaling images in browsers by anything other than multiples of two usually produces aliasing artifacts.

@timtylin

This comment has been minimized.

Show comment
Hide comment
@timtylin

timtylin Oct 28, 2013

Contributor

@mb21 This may be getting a bit off-topic, but I think there may be some potential to introduce style-sheet-like behavior in LaTeX by automatically custom-defining a figure macro for each image (named by identifier). Nothing concrete in my head yet, just throwing it out there.

LaTeX has always been a little bit unsatisfying to me because it's supposed to provide stylesheets to the TeX-style control character paradigm, but many of the current "de-facto" packages don't really work like pure stylesheets.

Contributor

timtylin commented Oct 28, 2013

@mb21 This may be getting a bit off-topic, but I think there may be some potential to introduce style-sheet-like behavior in LaTeX by automatically custom-defining a figure macro for each image (named by identifier). Nothing concrete in my head yet, just throwing it out there.

LaTeX has always been a little bit unsatisfying to me because it's supposed to provide stylesheets to the TeX-style control character paradigm, but many of the current "de-facto" packages don't really work like pure stylesheets.

@adityam

This comment has been minimized.

Show comment
Hide comment
@adityam

adityam Oct 29, 2013

Contributor

@evitaerc You mean something like the ConTeXt solution that I proposed earlier in this thread?

Contributor

adityam commented Oct 29, 2013

@evitaerc You mean something like the ConTeXt solution that I proposed earlier in this thread?

@timtylin

This comment has been minimized.

Show comment
Hide comment
@timtylin

timtylin Oct 29, 2013

Contributor

@adityam Similar, except for something compatible with existing LaTeX-based workflows. The main idea is to decouple specific layout-based information from syntactic information.

Contributor

timtylin commented Oct 29, 2013

@adityam Similar, except for something compatible with existing LaTeX-based workflows. The main idea is to decouple specific layout-based information from syntactic information.

@mb21

This comment has been minimized.

Show comment
Hide comment
@mb21

mb21 Oct 29, 2013

Collaborator

@evitaerc yes, I think that would be great. I'm no TeX guru, so is there a way to assign the same identifier to multiple images or figures (like an HTML class) in LaTeX and/or ConTeXt? Using unique identifiers (as suggested by @adityam) works as well, but is potentially quite a bit more cumbersome.

Collaborator

mb21 commented Oct 29, 2013

@evitaerc yes, I think that would be great. I'm no TeX guru, so is there a way to assign the same identifier to multiple images or figures (like an HTML class) in LaTeX and/or ConTeXt? Using unique identifiers (as suggested by @adityam) works as well, but is potentially quite a bit more cumbersome.

@adityam

This comment has been minimized.

Show comment
Hide comment
@adityam

adityam Oct 29, 2013

Contributor

@mb21 Yes, in ConTeXt you can assign the same identifier to multiple images. See context-wiki for details.

In practise, this works in the same way as CSS classes.

Contributor

adityam commented Oct 29, 2013

@mb21 Yes, in ConTeXt you can assign the same identifier to multiple images. See context-wiki for details.

In practise, this works in the same way as CSS classes.

@mb21

This comment has been minimized.

Show comment
Hide comment
@mb21

mb21 Oct 29, 2013

Collaborator

Oh, that's great. So ![image](file.jpg){class=myClass} could be translated to <img href="file.jpg" class="myClass" /> in HTML and \externalfigure[file.jpg][myClass] in ConTeXt. Output formats that don't support the notion of a class or non-unique identifier would just leave it out.

Collaborator

mb21 commented Oct 29, 2013

Oh, that's great. So ![image](file.jpg){class=myClass} could be translated to <img href="file.jpg" class="myClass" /> in HTML and \externalfigure[file.jpg][myClass] in ConTeXt. Output formats that don't support the notion of a class or non-unique identifier would just leave it out.

@mb21

This comment has been minimized.

Show comment
Hide comment
@mb21

mb21 Nov 14, 2013

Collaborator

Having thought about it a bit more, I propose the following syntax.

Headers

as already specified in the README
# My header {#id .class key=value key=value}

Images

as discussed here and in issues #170 and #813
![caption](image.png){#id .class}

which can be extended to
![caption](image.png){#id .class width=10cm width=600px} or ![caption](image.png){#id .class width=50%}

The HTML writer would ignore all cm-values and the TeX writers ignore the px-values. Both honor the %-values, so when using % you can use only one width key. Analogous for height.

Collaborator

mb21 commented Nov 14, 2013

Having thought about it a bit more, I propose the following syntax.

Headers

as already specified in the README
# My header {#id .class key=value key=value}

Images

as discussed here and in issues #170 and #813
![caption](image.png){#id .class}

which can be extended to
![caption](image.png){#id .class width=10cm width=600px} or ![caption](image.png){#id .class width=50%}

The HTML writer would ignore all cm-values and the TeX writers ignore the px-values. Both honor the %-values, so when using % you can use only one width key. Analogous for height.

@aaren

This comment has been minimized.

Show comment
Hide comment
@aaren

aaren Dec 9, 2013

@mb21

  1. why would you not comma separate the attributes inside {...}?

  2. What happens when you don't want to specify a class? e.g.

    ![caption](image.png){#id width=50%}
    

    What happens here? Are you suggesting that class should always be the second un-named argument?

aaren commented Dec 9, 2013

@mb21

  1. why would you not comma separate the attributes inside {...}?

  2. What happens when you don't want to specify a class? e.g.

    ![caption](image.png){#id width=50%}
    

    What happens here? Are you suggesting that class should always be the second un-named argument?

@mb21

This comment has been minimized.

Show comment
Hide comment
@mb21

mb21 Dec 9, 2013

Collaborator

@aaren

  1. It's space separated since we use that syntax already for headers.
  2. No, class is simply the argument starting with a dot, again as already used in the headers. If you don't specify a class the resulting image won't have any and you cannot style it with CSS or ConTeXt.
Collaborator

mb21 commented Dec 9, 2013

@aaren

  1. It's space separated since we use that syntax already for headers.
  2. No, class is simply the argument starting with a dot, again as already used in the headers. If you don't specify a class the resulting image won't have any and you cannot style it with CSS or ConTeXt.
@mb21

This comment has been minimized.

Show comment
Hide comment
@mb21

mb21 Mar 11, 2014

Collaborator

While there doesn’t appear to be consensus on how to explicitly specify image widths and heights, at least in HTML and ConTeXt the issue could be mostly avoided by using: ![caption](image.png){#id .class}

So now we’d have to change the definitions from...

  • Link [Inline] Target to Link Attr [Inline] Target and
  • Image [Inline] Target to Image Attr [Inline] Target.

This would solve #170. And while we are making breaking changes to Pandoc’s data format, we should probably add Attr also to Table (to solve #813) and maybe even to BlockQuote and Quoted (you never know).

When we see how people use these optional id and class attributes, we might develop a better understanding which additional key-value pairs like width and height are then still needed. These could then be added relatively easy without changing Pandoc’s data format yet again.

Collaborator

mb21 commented Mar 11, 2014

While there doesn’t appear to be consensus on how to explicitly specify image widths and heights, at least in HTML and ConTeXt the issue could be mostly avoided by using: ![caption](image.png){#id .class}

So now we’d have to change the definitions from...

  • Link [Inline] Target to Link Attr [Inline] Target and
  • Image [Inline] Target to Image Attr [Inline] Target.

This would solve #170. And while we are making breaking changes to Pandoc’s data format, we should probably add Attr also to Table (to solve #813) and maybe even to BlockQuote and Quoted (you never know).

When we see how people use these optional id and class attributes, we might develop a better understanding which additional key-value pairs like width and height are then still needed. These could then be added relatively easy without changing Pandoc’s data format yet again.

@jgm

This comment has been minimized.

Show comment
Hide comment
@jgm

jgm Aug 15, 2015

Owner

Still in progress, there's a PR that adds this.
I will probably merge it before long, but since
it is a breaking change with pandoc-types, I may
do another release in the 1.15 series first.

+++ gantech [Aug 14 15 05:57 ]:

Sorry for the noob comment. Still in progress right?


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

References

  1. #261 (comment)
Owner

jgm commented Aug 15, 2015

Still in progress, there's a PR that adds this.
I will probably merge it before long, but since
it is a breaking change with pandoc-types, I may
do another release in the 1.15 series first.

+++ gantech [Aug 14 15 05:57 ]:

Sorry for the noob comment. Still in progress right?


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

References

  1. #261 (comment)
@01AutoMonkey

This comment has been minimized.

Show comment
Hide comment
@01AutoMonkey

01AutoMonkey Aug 29, 2015

I basically can't use markdown right now because there isn't "support for defining image size", so looking forward to this feature!

I basically can't use markdown right now because there isn't "support for defining image size", so looking forward to this feature!

@flurin

This comment has been minimized.

Show comment
Hide comment
@flurin

flurin Sep 8, 2015

This would be really interesting as it would be quite trivial to write filters that could do things with these attributes as well (including other files come to mind)

flurin commented Sep 8, 2015

This would be really interesting as it would be quite trivial to write filters that could do things with these attributes as well (including other files come to mind)

@matteobachetti

This comment has been minimized.

Show comment
Hide comment
@crsh

This comment has been minimized.

Show comment
Hide comment

crsh commented Oct 21, 2015

👍

@legrostdg

This comment has been minimized.

Show comment
Hide comment
@legrostdg

legrostdg Oct 21, 2015

Is there still something preventing #2351 from being merged (except that it now has conflicts with the current master)?

Is there still something preventing #2351 from being merged (except that it now has conflicts with the current master)?

@jgm

This comment has been minimized.

Show comment
Hide comment
@jgm

jgm Oct 21, 2015

Owner

+++ legrostdg [Oct 21 15 07:23 ]:

Is there still something preventing [1]#2351 from being merged (except
that it now has conflicts with the current master)?

Mainly that it requires changes to pandoc-types and
everything that depends on this...it's a big API change.
I think we should be able to do it soon, though.

Owner

jgm commented Oct 21, 2015

+++ legrostdg [Oct 21 15 07:23 ]:

Is there still something preventing [1]#2351 from being merged (except
that it now has conflicts with the current master)?

Mainly that it requires changes to pandoc-types and
everything that depends on this...it's a big API change.
I think we should be able to do it soon, though.

@nichtich

This comment has been minimized.

Show comment
Hide comment
@nichtich

nichtich Oct 28, 2015

Contributor

Where is the best place to get to know and anticipate the coming changes? I bet the change can also affect custom pandoc filters so authors and developers should be pointed to a good description what to take care of.

On 21. Oktober 2015 16:57:17 MESZ, John MacFarlane notifications@github.com wrote:

+++ legrostdg [Oct 21 15 07:23 ]:

Is there still something preventing [1]#2351 from being merged
(except
that it now has conflicts with the current master)?

Mainly that it requires changes to pandoc-types and
everything that depends on this...it's a big API change.
I think we should be able to do it soon, though.


Reply to this email directly or view it on GitHub:
#261 (comment)

Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

Contributor

nichtich commented Oct 28, 2015

Where is the best place to get to know and anticipate the coming changes? I bet the change can also affect custom pandoc filters so authors and developers should be pointed to a good description what to take care of.

On 21. Oktober 2015 16:57:17 MESZ, John MacFarlane notifications@github.com wrote:

+++ legrostdg [Oct 21 15 07:23 ]:

Is there still something preventing [1]#2351 from being merged
(except
that it now has conflicts with the current master)?

Mainly that it requires changes to pandoc-types and
everything that depends on this...it's a big API change.
I think we should be able to do it soon, though.


Reply to this email directly or view it on GitHub:
#261 (comment)

Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

@dashed

This comment has been minimized.

Show comment
Hide comment
@dashed

dashed Nov 20, 2015

👍 Slick. Thanks @jgm!

dashed commented Nov 20, 2015

👍 Slick. Thanks @jgm!

@legrostdg

This comment has been minimized.

Show comment
Hide comment

\o/

@signalwerk

This comment has been minimized.

Show comment
Hide comment
@signalwerk

signalwerk Nov 20, 2015

Awesome! Thx!

Awesome! Thx!

@ambs

This comment has been minimized.

Show comment
Hide comment
@ambs

ambs Nov 20, 2015

WEEEEEEEEE!!!

ambs commented Nov 20, 2015

WEEEEEEEEE!!!

@katrinleinweber

This comment has been minimized.

Show comment
Hide comment

Merci! ☀️

@ivoanjo

This comment has been minimized.

Show comment
Hide comment
@ivoanjo

ivoanjo Nov 20, 2015

This is huge, thanks! 👍

ivoanjo commented Nov 20, 2015

This is huge, thanks! 👍

@frumbert

This comment has been minimized.

Show comment
Hide comment
@frumbert

frumbert Nov 23, 2015

Cool, but this won't be available in a full release until 1.16, right? I can't create a windows version of this branch using either stack or cabal.

Cool, but this won't be available in a full release until 1.16, right? I can't create a windows version of this branch using either stack or cabal.

@jgm

This comment has been minimized.

Show comment
Hide comment
@jgm

jgm Nov 23, 2015

Owner

+++ TIm St.Clair [Nov 22 15 17:41 ]:

Cool, but this won't be available in a full release until 1.16, right?
I can't create a windows version of this branch using either stack or
cabal.

What happens on Windows when you try with stack?

Owner

jgm commented Nov 23, 2015

+++ TIm St.Clair [Nov 22 15 17:41 ]:

Cool, but this won't be available in a full release until 1.16, right?
I can't create a windows version of this branch using either stack or
cabal.

What happens on Windows when you try with stack?

@frumbert

This comment has been minimized.

Show comment
Hide comment
@frumbert

frumbert Nov 23, 2015

Windows 2003 R2 Sp2 32-Bit, on VirtualBox; git, node, cygwin, miktex, haskell platform, cabal, etc all installed and updated ok. (ghc version 7.8.3)

$ stack install
Downloading lts-3.13 build plan ...FailedConnectionException2 "raw.githubusercon
tent.com" 443 True user error (cryptonite: random: cannot get any source of entr
opy on this system)

, and, when compiling via cabal, I also get cryptonite can't be installed (cryptonite: random: cannot get any source of entropy on this system).

Windows 2003 R2 Sp2 32-Bit, on VirtualBox; git, node, cygwin, miktex, haskell platform, cabal, etc all installed and updated ok. (ghc version 7.8.3)

$ stack install
Downloading lts-3.13 build plan ...FailedConnectionException2 "raw.githubusercon
tent.com" 443 True user error (cryptonite: random: cannot get any source of entr
opy on this system)

, and, when compiling via cabal, I also get cryptonite can't be installed (cryptonite: random: cannot get any source of entropy on this system).

@jgm

This comment has been minimized.

Show comment
Hide comment
@jgm

jgm Nov 23, 2015

Owner

https://hackage.haskell.org/package/cryptonite
says it supports Windows >= 8.

Is Windows 2003 < Windows 8? If so, that's your problem.

+++ TIm St.Clair [Nov 22 15 21:19 ]:

Windows 2003 R2 Sp2 32-Bit, on VirtualBox; git, node, cygwin, miktex,
haskell platform, cabal, etc all installed and updated ok. (ghc version
7.8.3)

$ stack install
Downloading lts-3.13 build plan ...FailedConnectionException2
"raw.githubusercon
tent.com" 443 True user error (cryptonite: random: cannot get any
source of entr
opy on this system)

when compiling via cabal, I also get cryptonite can't be installed
(cryptonite: random: cannot get any source of entropy on this system).


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

References

  1. #261 (comment)
Owner

jgm commented Nov 23, 2015

https://hackage.haskell.org/package/cryptonite
says it supports Windows >= 8.

Is Windows 2003 < Windows 8? If so, that's your problem.

+++ TIm St.Clair [Nov 22 15 21:19 ]:

Windows 2003 R2 Sp2 32-Bit, on VirtualBox; git, node, cygwin, miktex,
haskell platform, cabal, etc all installed and updated ok. (ghc version
7.8.3)

$ stack install
Downloading lts-3.13 build plan ...FailedConnectionException2
"raw.githubusercon
tent.com" 443 True user error (cryptonite: random: cannot get any
source of entr
opy on this system)

when compiling via cabal, I also get cryptonite can't be installed
(cryptonite: random: cannot get any source of entropy on this system).


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

References

  1. #261 (comment)
@frumbert

This comment has been minimized.

Show comment
Hide comment
@frumbert

frumbert Nov 23, 2015

slaps forehead
compiling happily on my win10 box...

i really have to trash that old thing and stop using it.

slaps forehead
compiling happily on my win10 box...

i really have to trash that old thing and stop using it.

@Wind4Greg

This comment has been minimized.

Show comment
Hide comment
@Wind4Greg

Wind4Greg Dec 8, 2015

I really want this feature but can't get Pandoc to build with stack on Windows 10. Followed the instructions from https://github.com/jgm/pandoc/wiki/Installing-the-development-version-of-pandoc, downloaded the latest stack from http://docs.haskellstack.org/en/stable/install_and_upgrade.html#windows. But I get a weird error seemingly unrelated to Pandoc:

    C:\Users\Greg\AppData\Local\Temp\stack5940\HTTP-4000.2.21\Network\HTTP\Proxy.hs:85:22:
        Not in scope: ‘liftM’
        Perhaps you meant ‘liftM2’ (imported from Control.Monad)

Which has something to do with a Haskell HTTP library. Is there any other way to get this feature? Or is there something about Haskell on windows that I'm overlooking.

I really want this feature but can't get Pandoc to build with stack on Windows 10. Followed the instructions from https://github.com/jgm/pandoc/wiki/Installing-the-development-version-of-pandoc, downloaded the latest stack from http://docs.haskellstack.org/en/stable/install_and_upgrade.html#windows. But I get a weird error seemingly unrelated to Pandoc:

    C:\Users\Greg\AppData\Local\Temp\stack5940\HTTP-4000.2.21\Network\HTTP\Proxy.hs:85:22:
        Not in scope: ‘liftM’
        Perhaps you meant ‘liftM2’ (imported from Control.Monad)

Which has something to do with a Haskell HTTP library. Is there any other way to get this feature? Or is there something about Haskell on windows that I'm overlooking.

@jgm

This comment has been minimized.

Show comment
Hide comment
@jgm

jgm Dec 8, 2015

Owner

Someone has reported the same issue on pandoc-discuss.
I haven't had a chance to build yet on a Windows machine or
investigate further.

+++ Greg Bernstein [Dec 08 15 11:31 ]:

I really want this feature but can't get Pandoc to build with stack on
Windows 10. Followed the instructions from
[1]https://github.com/jgm/pandoc/wiki/Installing-the-development-versio
n-of-pandoc, downloaded the latest stack from
[2]http://docs.haskellstack.org/en/stable/install_and_upgrade.html#wind
ows. But I get a weird error seemingly unrelated to Pandoc:
C:\Users\Greg\AppData\Local\Temp\stack5940\HTTP-4000.2.21\Network\HTTP\Proxy
.hs:85:22:
Not in scope: ‘liftM’
Perhaps you meant ‘liftM2’ (imported from Control.Monad)

Which has something to do with a Haskell HTTP library. Is there any
other way to get this feature? Or is there something about Haskell on
windows that I'm overlooking.


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

References

  1. https://github.com/jgm/pandoc/wiki/Installing-the-development-version-of-pandoc
  2. http://docs.haskellstack.org/en/stable/install_and_upgrade.html#windows
  3. #261 (comment)
Owner

jgm commented Dec 8, 2015

Someone has reported the same issue on pandoc-discuss.
I haven't had a chance to build yet on a Windows machine or
investigate further.

+++ Greg Bernstein [Dec 08 15 11:31 ]:

I really want this feature but can't get Pandoc to build with stack on
Windows 10. Followed the instructions from
[1]https://github.com/jgm/pandoc/wiki/Installing-the-development-versio
n-of-pandoc, downloaded the latest stack from
[2]http://docs.haskellstack.org/en/stable/install_and_upgrade.html#wind
ows. But I get a weird error seemingly unrelated to Pandoc:
C:\Users\Greg\AppData\Local\Temp\stack5940\HTTP-4000.2.21\Network\HTTP\Proxy
.hs:85:22:
Not in scope: ‘liftM’
Perhaps you meant ‘liftM2’ (imported from Control.Monad)

Which has something to do with a Haskell HTTP library. Is there any
other way to get this feature? Or is there something about Haskell on
windows that I'm overlooking.


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

References

  1. https://github.com/jgm/pandoc/wiki/Installing-the-development-version-of-pandoc
  2. http://docs.haskellstack.org/en/stable/install_and_upgrade.html#windows
  3. #261 (comment)
@Wind4Greg

This comment has been minimized.

Show comment
Hide comment
@Wind4Greg

Wind4Greg Dec 8, 2015

Thanks. It's a windows/Haskell issue, using a VM was able to build it on Ubuntu and see first hand this really nice feature. I'll watch pandoc-discuss for the windows fix.
Cheers.

Thanks. It's a windows/Haskell issue, using a VM was able to build it on Ubuntu and see first hand this really nice feature. I'll watch pandoc-discuss for the windows fix.
Cheers.

@mindv0rtex

This comment has been minimized.

Show comment
Hide comment
@mindv0rtex

mindv0rtex Mar 31, 2016

Is there an estimate of when this feature will reach the release?

Is there an estimate of when this feature will reach the release?

@mb21

This comment has been minimized.

Show comment
Hide comment
@mb21

mb21 Mar 31, 2016

Collaborator

Image dimensions have been in 1.16 for a while already...

Collaborator

mb21 commented Mar 31, 2016

Image dimensions have been in 1.16 for a while already...

@mindv0rtex

This comment has been minimized.

Show comment
Hide comment
@mindv0rtex

mindv0rtex Mar 31, 2016

Oops, my bad!

Oops, my bad!

@mofosyne

This comment has been minimized.

Show comment
Hide comment
@mofosyne

mofosyne May 17, 2016

How do you use it btw? I can't seem to find instructions on using it in the manual.

How do you use it btw? I can't seem to find instructions on using it in the manual.

@KurtPfeifle

This comment has been minimized.

Show comment
Hide comment

@mofosyne:

Search for link_attributes.

See here: http://pandoc.org/README.html#images

@flrgsr

This comment has been minimized.

Show comment
Hide comment
@flrgsr

flrgsr Jun 16, 2017

It seems this only works with the width and height keyword.
What about scale?

I would love to be able to do something like this:

![image description](images/myimage.png){ scale=0.5 }

Am I missing something or is this really impossible yet?

edit: I care about the latex backend

So as desired output I would like to have:
\begin{figure} \centering \includegraphics[scale=0.5]{images/myimage.png} \caption{the caption goes here} \end{figure}

flrgsr commented Jun 16, 2017

It seems this only works with the width and height keyword.
What about scale?

I would love to be able to do something like this:

![image description](images/myimage.png){ scale=0.5 }

Am I missing something or is this really impossible yet?

edit: I care about the latex backend

So as desired output I would like to have:
\begin{figure} \centering \includegraphics[scale=0.5]{images/myimage.png} \caption{the caption goes here} \end{figure}

labdsf pushed a commit that referenced this issue Nov 5, 2017

@JonasT

This comment has been minimized.

Show comment
Hide comment
@JonasT

JonasT Nov 21, 2017

Similarly to @flrgsr I would like to be able to scale images, mainly so that I don't need to make all my images super low-res and/or hardcode the image sizes in the markdown just to accommodate the scaling with HTML (which is super low DPI per default).

JonasT commented Nov 21, 2017

Similarly to @flrgsr I would like to be able to scale images, mainly so that I don't need to make all my images super low-res and/or hardcode the image sizes in the markdown just to accommodate the scaling with HTML (which is super low DPI per default).

@mb21

This comment has been minimized.

Show comment
Hide comment
@mb21

mb21 Nov 21, 2017

Collaborator

It sounds what you guys are really looking for is:

![](image.jpg){srcset="image_2x.jpg 2x"}
Collaborator

mb21 commented Nov 21, 2017

It sounds what you guys are really looking for is:

![](image.jpg){srcset="image_2x.jpg 2x"}
@JonasT

This comment has been minimized.

Show comment
Hide comment
@JonasT

JonasT Nov 21, 2017

Yes! Is there a nicer way to write that? Also, does that work with all backends (e.g. both PDF and HTML)?

Edit: also if this actually scales up/down the pixels before inserting the image that doesn't help, since then it will reduce the resolution. I can do that myself in GIMP - the point is scaling down the size without reducing the image resolution to support high DPI output properly

JonasT commented Nov 21, 2017

Yes! Is there a nicer way to write that? Also, does that work with all backends (e.g. both PDF and HTML)?

Edit: also if this actually scales up/down the pixels before inserting the image that doesn't help, since then it will reduce the resolution. I can do that myself in GIMP - the point is scaling down the size without reducing the image resolution to support high DPI output properly

@mb21

This comment has been minimized.

Show comment
Hide comment
@mb21

mb21 Nov 21, 2017

Collaborator

Depending on your taste, it's already quite nice.. (at least it's consistent with other syntax) see http://pandoc.org/MANUAL.html#extension-link_attributes for the rationale.

No, if you generate your PDF with LaTeX (which is the default), it will use image.jpg. You can always write a filter that scales your images, or write some CSS to your needs...

Collaborator

mb21 commented Nov 21, 2017

Depending on your taste, it's already quite nice.. (at least it's consistent with other syntax) see http://pandoc.org/MANUAL.html#extension-link_attributes for the rationale.

No, if you generate your PDF with LaTeX (which is the default), it will use image.jpg. You can always write a filter that scales your images, or write some CSS to your needs...

@JonasT

This comment has been minimized.

Show comment
Hide comment
@JonasT

JonasT Nov 21, 2017

So what about HTML? HTML is one of my required main targets so if it's not working nicely there, sadly I can't really use it.

Filters are often mentioned here, but I consider them quite uninteresting since they require something outside markdown. Similar to CSS, except CSS is even a lot worse since it requires specific stuff for one output format only. Write once in a universal format, output to all targets shouldn't require this..

JonasT commented Nov 21, 2017

So what about HTML? HTML is one of my required main targets so if it's not working nicely there, sadly I can't really use it.

Filters are often mentioned here, but I consider them quite uninteresting since they require something outside markdown. Similar to CSS, except CSS is even a lot worse since it requires specific stuff for one output format only. Write once in a universal format, output to all targets shouldn't require this..

@mb21

This comment has been minimized.

Show comment
Hide comment
@mb21

mb21 Nov 21, 2017

Collaborator

So what about HTML?

What about it? Tell us what HTML you expect pandoc to generate for what input...

Filters are often mentioned here, but I consider them quite uninteresting since they require something outside markdown.

That's not correct. Filters are for you to customize pandoc's behaviour, see https://pandoc.org/scripting.html

But this discussion/QA should move to pandoc-discuss. This issue is closed and we're spamming the people subscribed to it.

Collaborator

mb21 commented Nov 21, 2017

So what about HTML?

What about it? Tell us what HTML you expect pandoc to generate for what input...

Filters are often mentioned here, but I consider them quite uninteresting since they require something outside markdown.

That's not correct. Filters are for you to customize pandoc's behaviour, see https://pandoc.org/scripting.html

But this discussion/QA should move to pandoc-discuss. This issue is closed and we're spamming the people subscribed to it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment