From: <mi...@pc...> - 2005-05-17 15:51:04
|
Hello All, I have a couple of questions about figures. First of all the :align: setting for figures only applies to the image part of the figure. This is probably correct as far as the documentation goes - but it breaks the figure. In order to float a figure to the right I'm putting the figure in a class, which works fine. What it means is the the :align: option for figures is useless (although I may be mistaken - I think that did happen once before :-) - using it breaks the figure. It would be more useful for :align: to apply to the figure rather than the image (or maybe add :figalign:). Also I found that ``:figwidth: image`` just plain didn't work for me. Explicitly setting the width to the width of the image did though. I can provide an example if it's helpful - I do have PIL installed, but it shouldn't be needed because I'm explicitly specifying image width. Best Regards, Fuzzy http://www.voidspace.org.uk/python |
From: Felix W. <Fel...@gm...> - 2005-05-20 22:39:13
|
mi...@pc... wrote: > I have a couple of questions about figures. > > First of all the :align: setting for figures only applies to the image part of > the figure. Not in the current SVN sources. Please take a look at <http://docutils.sf.net/test/functional/expected/standalone_rst_html4css1.html#images> if that suits your needs. > Also I found that ``:figwidth: image`` just plain didn't work for me. Thanks for your report on SF.net [1] -- fixed. We need to test this, but unfortunately it requires some checking in the test code if PIL is available... Not in the mood to do that currently. Added to to-do list. [1] http://sourceforge.net/tracker/index.php?func=detail&aid=1202510&group_id=38414&atid=422030 -- For private mail please ensure that the header contains 'Felix Wiemann'. http://www.ososo.de/ |
From: <mi...@pc...> - 2005-05-21 09:32:41
|
Quoting Felix Wiemann <Fel...@gm...>: > mi...@pc... wrote: > >> I have a couple of questions about figures. >> >> First of all the :align: setting for figures only applies to the >> image part of >> the figure. > > Not in the current SVN sources. Please take a look at > <http://docutils.sf.net/test/functional/expected/standalone_rst_html4css1.html#images> > if that suits your needs. > Ahh... it must have changed recently. I'm using a version more recent than 0.3.7. Thank you. >> Also I found that ``:figwidth: image`` just plain didn't work for me. > > Thanks for your report on SF.net [1] -- fixed. > > We need to test this, but unfortunately it requires some checking in the > test code if PIL is available... Not in the mood to do that currently. > Added to to-do list. > Right - I was using it when *explicitly* specifying an image width, so it shouldn't need PIL in that situation. Thanks Fuzzy > [1] > http://sourceforge.net/tracker/index.php?func=detail&aid=1202510&group_id=38414&atid=422030 > > -- > For private mail please ensure that the header contains 'Felix Wiemann'. > > http://www.ososo.de/ > > > > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click > _______________________________________________ > Docutils-users mailing list > Doc...@li... > https://lists.sourceforge.net/lists/listinfo/docutils-users > > Please use "Reply All" to reply to the list. > |
From: Nicolas G. <nic...@ne...> - 2005-05-26 13:07:14
|
Hi all, currently image & figure directives offer options to control the associated image's dimensions, when the output format is html; I've tried to use them but couldn't get to a satisfying result in LaTeX. Basically I need the generated LaTeX code of *some* images to be:: \includegraphics[angle=90,width=18cm]{img} instead of:: \includegraphics{img} Is there a way of achieving this ? Thanks in advance, cheers, Nicolas |
From: <gr...@us...> - 2005-05-27 08:36:08
|
On Thu, 26 May 2005, Nicolas Girard wrote: > Hi all, > > currently image & figure directives offer options to control the > associated image's dimensions, when the output format is html; > > I've tried to use them but couldn't get to a satisfying result in LaTeX. > Basically I need the generated LaTeX code of *some* images to be:: > > \includegraphics[angle=90,width=18cm]{img} > > instead of:: > > \includegraphics{img} > > > Is there a way of achieving this ? there is scaling support in the latexwriter. do you need html and latex ? a short sample would be helpful cheers -- BINGO: high-performance breakthrough |
From: Felix W. <Fel...@gm...> - 2005-05-27 18:21:34
|
Nicolas Girard wrote: > [There are] options to control the associated image's dimensions [...] > > I've tried to use them but couldn't get to a satisfying result in LaTeX. That's because the :width: option specifies pixels, but in a typeset document there is no such thing as a "pixel". Thus it would be good to have support for length units. I suggest we use the following units: * em (ems, the height of the element's font) * ex (x-height, the height of the letter "x") * px (pixels, relative to the canvas resolution) * in (inches; 1in=2.54cm) * cm (centimeters; 1cm=10mm) * mm (millimeters) * pt (points; 1pt=1/72in) * pc (picas; 1pc=12pt) * % (percentage of the current line width) Taken from <http://www.htmlhelp.com/reference/css/units.html#length>. They're all supported by CSS1, and LaTeX supports all except px (should be replaced with pt probably). The reST parser would add "px" to raw numbers. Comments? > Basically I need the generated LaTeX code of *some* images to be:: > > \includegraphics[angle=90,width=18cm]{img} If you need rotated images, I'd recommend you simply write:: .. raw:: latex \includegraphics[angle=90,width=18cm]{img} You could also pre-rotate the images, of course. -- For private mail please ensure that the header contains 'Felix Wiemann'. http://www.ososo.de/ |
From: Nicolas G. <nic...@ne...> - 2005-05-29 15:53:06
|
On Friday 27 May 2005 20:17, Felix Wiemann wrote: > Nicolas Girard wrote: > > [There are] options to control the associated image's dimensions [...] > > > > I've tried to use them but couldn't get to a satisfying result in LaTeX. > > That's because the :width: option specifies pixels, but in a typeset > document there is no such thing as a "pixel". > > Thus it would be good to have support for length units. I suggest we > use the following units: > > * em (ems, the height of the element's font) > * ex (x-height, the height of the letter "x") > * px (pixels, relative to the canvas resolution) > * in (inches; 1in=2.54cm) > * cm (centimeters; 1cm=10mm) > * mm (millimeters) > * pt (points; 1pt=1/72in) > * pc (picas; 1pc=12pt) > * % (percentage of the current line width) > > Taken from <http://www.htmlhelp.com/reference/css/units.html#length>. > They're all supported by CSS1, and LaTeX supports all except px (should > be replaced with pt probably). > > The reST parser would add "px" to raw numbers. > > Comments? Well...that'd be very useful IMHO ; your list seems accurate to me. > > > Basically I need the generated LaTeX code of *some* images to be:: > > > > \includegraphics[angle=90,width=18cm]{img} > > If you need rotated images, I'd recommend you simply write:: > > .. raw:: latex > > \includegraphics[angle=90,width=18cm]{img} > OK, that's fine, it's enough to me. Thanks for the tip ! Oh, wait: I'm not in this situation now, but suppose I'd like my ReST document to be converted both into LaTeX and HTML, would your tip behave as expected ? I mean, have an <a> tag added to the html document as usual, and the custom \includegraphics in the LaTeX source ? Cheers |
From: Felix W. <Fel...@gm...> - 2005-05-29 18:54:38
|
Nicolas Girard wrote: > Felix Wiemann wrote: > >> If you need rotated images, I'd recommend you simply write:: >> >> .. raw:: latex >> >> \includegraphics[angle=90,width=18cm]{img} > > OK, that's fine, it's enough to me. Thanks for the tip ! > > Oh, wait: I'm not in this situation now, but suppose I'd like my ReST > document to be converted both into LaTeX and HTML, would your tip > behave as expected? I mean, have an <a> tag added to the html > document as usual, and the custom \includegraphics in the LaTeX > source? You mean an <img> tag in HTML I suppose? No, that wouldn't work. We would need a new directive (e.g. "output-format") which could be used like this:: .. raw:: latex \includegraphics... .. output-format:: not latex .. image:: ... The to-do list already has an entry for that, <http://docutils.sf.net/docs/dev/todo.html#conditional-directives>. I don't understand the example with the ``eqn`` directive there, though. -- For private mail please ensure that the header contains 'Felix Wiemann'. http://www.ososo.de/ |
From: Alan G I. <ai...@am...> - 2005-05-29 22:36:39
|
On Sun, 29 May 2005, Felix Wiemann apparently wrote: > .. raw:: latex > \includegraphics... > .. output-format:: not latex > .. image:: ... Wouldn't it be easier to understand something along the lines of:: .. image:: fig.eps fig.txt fig.png :writer-is: latex :options: :writer-is: text-only :options: :writer-is: other :options: Cheers, Alan Isaac |
From: Mikolaj M. <mi...@wp...> - 2005-05-30 09:12:13
|
Dnia poniedziałek 30 maj 2005 00:18, Alan G Isaac napisał: > Wouldn't it be easier to understand something along > the lines of:: > > .. image:: fig.eps fig.txt fig.png > :writer-is: latex > :options: > :writer-is: text-only > :options: > :writer-is: other > :options: > In that scenario personally I would prefer .. image:: fig :writer-is: latex :options: :writer-is: text-only :options: :writer-is: other :options: Name without extension. And declare it in options of writer (and/or have some defaults). m. |
From: Felix W. <Fel...@gm...> - 2005-05-31 20:44:55
|
Alan G Isaac wrote: > Felix Wiemann wrote: > >> .. raw:: latex >> >> \includegraphics... >> >> .. output-format:: not latex >> >> .. image:: ... > > Wouldn't it be easier to understand something along the lines of:: > > .. image:: fig.eps fig.txt fig.png > :writer-is: latex > :options: > :writer-is: text-only > :options: > :writer-is: other > :options: No, because in this case, it wouldn't solve the problem (passing arbitrary options to \includegraphics), so the solution isn't generic enough. Conditional reST code is nothing I'd put into the options of directives. -- For private mail please ensure that the header contains 'Felix Wiemann'. http://www.ososo.de/ |
From: Alan G I. <ai...@am...> - 2005-05-31 21:25:13
|
>> Felix Wiemann wrote: >>> .. raw:: latex >>> \includegraphics... >>> .. output-format:: not latex >>> .. image:: ... > Alan G Isaac wrote: >> Wouldn't it be easier to understand something along the lines of:: >> .. image:: fig.eps fig.txt fig.png >> :writer-is: latex >> :options: >> :writer-is: text-only >> :options: >> :writer-is: other >> :options: On Tue, 31 May 2005, Felix Wiemann apparently wrote: > No, because in this case, it wouldn't solve the problem (passing > arbitrary options to \includegraphics), so the solution isn't generic > enough. That may be, but I think I asked a different question? And the raw directive is always available if needed. > Conditional reST code is nothing I'd put into the options of > directives. I do not pretend to know all the trade-offs, but readability is the one I was emphasizing. :: .. output-format:: not latex .. image:: fig.png :options: is distracting. Even the following is better:: .. image:: fig.png :writer-is: not-latex :options: Cheers, Alan Isaac |
From: David G. <go...@py...> - 2005-06-01 01:37:34
Attachments:
signature.asc
|
[Alan G Isaac] >>> Wouldn't it be easier to understand something along the lines of:: >>> .. image:: fig.eps fig.txt fig.png >>> :writer-is: latex >>> :options: >>> :writer-is: text-only >>> :options: >>> :writer-is: other >>> :options: ... > I do not pretend to know all the trade-offs, > but readability is the one I was emphasizing. :: > > .. output-format:: not latex > .. image:: fig.png > :options: > > is distracting. How so? Such a statement is totally unconvincing without supporting arguments. > Even the following is better:: > > .. image:: fig.png > :writer-is: not-latex > :options: If we're going to have some kind of conditional in reST, it's going to be orthogonal to other directives, not part of them. Otherwise, we'd have to implement such options on every directive. Much easier (programmatically *and* conceptually, IMO) to implement it once as a generic directive, and let it have arbitrary content. -- David Goodger <http://python.net/~goodger> |
From: Alan G I. <ai...@am...> - 2005-06-01 12:22:21
|
On Tue, 31 May 2005, David Goodger apparently wrote: > How so? Because the *reader* of an reST document does not care about the output format but does care about the image inclusion. This consideration is even more obvious in the multiformat example I offered. But as I said, I was addressing *only* one consideration: readability. Life is full of trade-offs. Cheers, Alan Isaac |
From: Nicolas G. <nic...@ne...> - 2005-05-30 22:15:50
|
On Friday 27 May 2005 20:17, Felix Wiemann wrote: > Thus it would be good to have support for length units. I suggest we > use the following units: > > * em (ems, the height of the element's font) I was a bit confused with this statement, because it looked true to me, while at the same time I had in mind that em was related to the width of the "m" letter. Then I finally found this `page`_ which made it much clearer: there seems to be a misunderstanding of this unit among the TeX community, to my surprise... Cheers, Nicolas .. page_: http://doubletype.sourceforge.net/?about%20em |
From: Felix W. <Fel...@gm...> - 2005-05-31 20:49:06
|
gr...@us... wrote: > shouldnt this be in the latex.txt file, currently it says : > > pdf-image inclusion in pdf files fails, specify > --graphicx-option=pdftex or --graphicx-option=auto. > > maybe should be : > > If pdf-image inclusion in pdf files fails, specify > --graphicx-option=pdftex or --graphicx-option=auto. Yes, you might want to change this. However, I have to say that I never needed this graphicx option, so I can't tell if it's really necessary. -- For private mail please ensure that the header contains 'Felix Wiemann'. http://www.ososo.de/ |
From: Felix W. <Fel...@gm...> - 2005-06-16 22:10:21
|
David Goodger wrote: > Felix Wiemann wrote: > >> Thus it would be good to have support for length units. > > It's been discussed before. See > <http://docutils.sf.net/docs/dev/todo.html#units-of-measure>. Except that this time we actually implement it. :-) Done. Percentage units for image heights aren't supported because there is no universal notion of a "page height", and specifying image heights relative to the current line *width* is counter-intuitive and not needed in practice. The unit stuff can (and should) be extended to other uses, e.g. figure widths and table column widths. We can do that later. -- For private mail please ensure that the header contains 'Felix Wiemann'. "the number of contributors [...] is strongly and inversely correlated with the number of hoops each project makes a contributing user go through." -- ESR |
From: Nicolas G. <nic...@ne...> - 2005-05-27 09:04:32
|
On Friday 27 May 2005 10:36, gr...@us... wrote: > On Thu, 26 May 2005, Nicolas Girard wrote: > > Hi all, > > > > currently image & figure directives offer options to control the > > associated image's dimensions, when the output format is html; > > > > I've tried to use them but couldn't get to a satisfying result in LaTeX. > > Basically I need the generated LaTeX code of *some* images to be:: > > > > \includegraphics[angle=90,width=18cm]{img} > > > > instead of:: > > > > \includegraphics{img} > > > > > > Is there a way of achieving this ? > > there is scaling support in the latexwriter. > > do you need html and latex ? > I'm afraid I don't understand your question, but I can detail my needs: I'm currently generating reports of astrophysical simulations. Basically each simulation produces data; data is analyzed and as a result figures are created. With my toole I can associate comments (in ReST) on both data and figures. Finally a report in ReST is generated by putting together the title, some autogenerated tables & sections, inclusions of figures and comments. (this is a situation where ReST particularly rocks, by the way ;-) OK, now for the tricky point: - I'd like the final document to be outputted from pdflatex ; - as you know, pdflatex doesn't know about eps files, then my figures can't be in eps but in an oter format - the consequence is that I can't specify the dimensions & orientation of the figures in the associated files themselves, as it would be possible using eps; - some figures *must* take as much place as possible in an A4 page, and *must* have width > height - then, for these figures, I must at least specify that they should rotated ; as for their size, I'd need them to take as much place as possible, but the time will come soon when I'll want to precisely control the dimensions of some images in the document. I'm not sure if this helps, please tell me if you want any precisions. Cheers Nicolas |
From: <gr...@us...> - 2005-05-27 09:35:21
|
On Fri, 27 May 2005, Nicolas Girard wrote: > On Friday 27 May 2005 10:36, gr...@us... wrote: >> On Thu, 26 May 2005, Nicolas Girard wrote: >>> Hi all, >>> >>> currently image & figure directives offer options to control the >>> associated image's dimensions, when the output format is html; >>> >>> I've tried to use them but couldn't get to a satisfying result in LaTeX. >>> Basically I need the generated LaTeX code of *some* images to be:: >>> >>> \includegraphics[angle=90,width=18cm]{img} Felix, David: should angle be attribute "angle" or "rotate" ? >>> instead of:: >>> >>> \includegraphics{img} >>> >>> >>> Is there a way of achieving this ? >> >> there is scaling support in the latexwriter. >> >> do you need html and latex ? >> > I'm afraid I don't understand your question, but I can detail my needs: > > I'm currently generating reports of astrophysical simulations. Basically each > simulation produces data; data is analyzed and as a result figures are > created. With my toole I can associate comments (in ReST) on both data and > figures. Finally a report in ReST is generated by putting together the title, > some autogenerated tables & sections, inclusions of figures and comments. > > (this is a situation where ReST particularly rocks, by the way ;-) > > OK, now for the tricky point: > - I'd like the final document to be outputted from pdflatex ; > - as you know, pdflatex doesn't know about eps files, then my figures can't be > in eps but in an oter format no i didnt know it and it sounds strange as i always thought pdf is scaled down ps. from http://lists.gnu.org/archive/html/adonthell-devel/2002-09/msg00006.html snip ------- For those that are interested, using .ps gfx with pdflatex works as follows: * In your latex header, include the following lines: \usepackage[pdftex]{graphicx} \usepackage{epstopdf} The epstopdf package is available at http://www.ctan.org/tex-archive/macros/latex/contrib/supported/oberdiek/epstopdf.sty * You also need the epstopdf program. There's a perl script for Unix and I also read about a binary for Windows. Might come with your latex distro already. * To properly include the graphics, they should be in eps format, with a correct bounding box. I found a tool called ps2eps that takes care of that: http://www.tm.uka.de/~bless/ps2eps * Afterwards, you can use \includegraphics{filename.eps} to include them. pdflatex will take care of converting them to pdf format on the fly. Of course you could also convert them manually and just \includegraphics{filename.pdf}. In latter case, you don't even have to \usepackage{epstopdf}. ------- so the way is include pdf files (i did so recently in a perl project) > - the consequence is that I can't specify the dimensions & orientation of the > figures in the associated files themselves, as it would be possible using > eps; width/size might be set when generating the picture files pdf or png or gif, so only the rotation must be specified in the ReST document. > - some figures *must* take as much place as possible in an A4 page, and *must* > have width > height > - then, for these figures, I must at least specify that they should rotated ; > as for their size, I'd need them to take as much place as possible, but the > time will come soon when I'll want to precisely control the dimensions of > some images in the document. > > I'm not sure if this helps, please tell me if you want any precisions. helps a lot thanks. * currently the latexwriter respects scale and align. * scale is implemented by a scalebox around includegraphics. * rotation is missing did i get it clear and correct cheers -- BINGO: Think outside the box |
From: Nicolas G. <nic...@ne...> - 2005-05-27 09:57:58
|
On Friday 27 May 2005 11:35, gr...@us... wrote: > On Fri, 27 May 2005, Nicolas Girard wrote: > no i didnt know it and it sounds strange as i always thought pdf is scaled > down ps. > > from > http://lists.gnu.org/archive/html/adonthell-devel/2002-09/msg00006.html > > snip ------- > For those that are interested, using .ps gfx with pdflatex works as > follows [...] oh, ok fine, I didn't know about this ! I'll try it today, thanks ! > > width/size might be set when generating the picture files pdf or png or > gif, so only the rotation must be specified in the ReST document. > > [...] > > * currently the latexwriter respects scale and align. > * scale is implemented by a scalebox around includegraphics. > > * rotation is missing > > did i get it clear and correct > Yes I think so ; but it would be very useful if one could specify *absolute* dimensions of images using the "width" & "height" properties, as well as *relative* dimensions using the "scale" property. If I understood correctly (and I think I've tested that also) the width & height props currently only make sense as pixels for the html output ; it would be great if one could specify:: :width: 15cm so that the corresponding image in the LaTeX output has a width of 15 cm. I guess there's a difficulty of implementation here, because when combined with a ":rotate:" option the width could refer to either the original width or the width of the rotated image ; iirc the latex package takes care of the order of the dimensions specifications with respect to the rotation specification. Then if the docutils LaTeX writer was to implement these options in a samilar way as the LaTeX package, it should treat the image elements' properties as an *ordered* list, which may not be currently the case... cheers, Nicolas |
From: Felix W. <Fel...@gm...> - 2005-05-27 18:35:19
|
gr...@us... wrote: > Nicolas Girard wrote: > >>>> \includegraphics[angle=90,width=18cm]{img} > > Felix, David: should angle be attribute "angle" or "rotate" ? None of both, -1, sorry. I don't want support for rotated images in reST for three reasons: * It's not possible to implement rotating with all output formats. * It's not needed very often. * You can achieve the same effect by pre-rotating the image. > [...] Of course you could also convert them manually and just > \includegraphics{filename.pdf}. Two things to note: * The extension is ignored by graphicx, so you can ommit the ".pdf". (Esp. handy if you want a file to be processable by both latex and pdflatex.) In fact, IIRC \includegraphics will pick up file.png even if you specify \includegraphics{file.pdf} (provided that file.png exists of course). Very annoying, but I think it can be changed somehow (see grfguide.pdf). * Including PDF files is *way* faster than including PNG files. Thus, processing by pdflatex may be sped up significantly by pre-converting all PNG files to PDF, using convert (from ImageMagick) or png2pdf (<http://png2pdf.sf.net/>). You don't even need to change the reST/LaTeX file; the PDF files are picked up automatically provided that you delete the PNG files. -- For private mail please ensure that the header contains 'Felix Wiemann'. http://www.ososo.de/ |
From: <gr...@us...> - 2005-05-27 19:20:51
|
On Fri, 27 May 2005, Felix Wiemann wrote: > gr...@us... wrote: > >> Nicolas Girard wrote: >> >>>>> \includegraphics[angle=90,width=18cm]{img} >> >> Felix, David: should angle be attribute "angle" or "rotate" ? > > None of both, -1, sorry. I don't want support for rotated images in > reST for three reasons: > > * It's not possible to implement rotating with all output formats. wouldnt stop me from anything, there are no images in rest firsthand. > * It's not needed very often. > * You can achieve the same effect by pre-rotating the image. but your absolutely right especially in this case as the images are created and the ReST document so instead of putting the rotate-attribute into the rest document one could rotate the image as easily. >> [...] Of course you could also convert them manually and just >> \includegraphics{filename.pdf}. > > Two things to note: > > * The extension is ignored by graphicx, so you can ommit the ".pdf". > (Esp. handy if you want a file to be processable by both latex and > pdflatex.) In fact, IIRC \includegraphics will pick up file.png even > if you specify \includegraphics{file.pdf} (provided that file.png > exists of course). Very annoying, but I think it can be changed > somehow (see grfguide.pdf). > > * Including PDF files is *way* faster than including PNG files. Thus, > processing by pdflatex may be sped up significantly by pre-converting > all PNG files to PDF, using convert (from ImageMagick) or png2pdf > (<http://png2pdf.sf.net/>). shouldnt this be in the latex.txt file, currently it says : pdf-image inclusion in pdf files fails, specify --graphicx-option=pdftex or --graphicx-option=auto. maybe should be : If pdf-image inclusion in pdf files fails, specify --graphicx-option=pdftex or --graphicx-option=auto. cheers -- BINGO: enthusiastically administrate high-quality products |
From: David G. <go...@py...> - 2005-06-07 02:44:16
Attachments:
signature.asc
|
[Felix Wiemann] > Thus it would be good to have support for length units. It's been discussed before. See <http://docutils.sf.net/docs/dev/todo.html#units-of-measure>. > I suggest we use the following units: > > * em (ems, the height of the element's font) > * ex (x-height, the height of the letter "x") > * px (pixels, relative to the canvas resolution) > * in (inches; 1in=2.54cm) > * cm (centimeters; 1cm=10mm) > * mm (millimeters) > * pt (points; 1pt=1/72in) > * pc (picas; 1pc=12pt) > * % (percentage of the current line width) > > Taken from > <http://www.htmlhelp.com/reference/css/units.html#length>. They're > all supported by CSS1, and LaTeX supports all except px (should be > replaced with pt probably). > > The reST parser would add "px" to raw numbers. > > Comments? As long as it remains backward-compatible, +1. However, the parser should not add any units, but leave the default units "implied" (as in the XML DTD meaning "#IMPLIED"). The writers should assign units as appropriate (e.g. px for HTML, pt for LaTeX and other print formats). -- David Goodger <http://python.net/~goodger> |