Hello,

When using shadings with different layers Adobe Reader becomes
extremely slow to render the image. For example 2 layers, the first
(foregroup) is quickly displayed while the background is set
about 5 to 10 seconds later !

I suspect this is because pdf produces vectorial images.

Is there a turn around ? Or a possibility to transform the
vectorial image into a bitmap/jpeg/png one ? Preferably
within the compilation...

Thanks in advance.

On Mon, 28 Mar 2011 20:42:48 +0200, GL wrote:

 > When using shadings with different layers Adobe Reader becomes
 > extremely slow to render the image. For example 2 layers, the first
 > (foregroup) is quickly displayed while the background is set
 > about 5 to 10 seconds later !

Try some other PDF viewers to see whether it's just the Adobe
Reader that is having problems.

 > Is there a turn around ? Or a possibility to transform the
 > vectorial image into a bitmap/jpeg/png one ? Preferably
 > within the compilation...

It's quite likely that any such conversion will be just as slow
as rendering by a PDF viewer.

Bob T.

Le 28/03/2011 22:25, Bob Tennent a �crit :
> On Mon, 28 Mar 2011 20:42:48 +0200, GL wrote:
>
>   >  When using shadings with different layers Adobe Reader becomes
>   >  extremely slow to render the image. For example 2 layers, the first
>   >  (foregroup) is quickly displayed while the background is set
>   >  about 5 to 10 seconds later !
>
> Try some other PDF viewers to see whether it's just the Adobe
> Reader that is having problems.

Yes it's the same for FireFox. TeXWorks does not display the opacity
and ghostview neither...

The problem - IFAIK - is that it's not an image: it's a vector.
For an image management software, on intel core i7, this is child play.

>   >  Is there a turn around ? Or a possibility to transform the
>   >  vectorial image into a bitmap/jpeg/png one ? Preferably
>   >  within the compilation...
>
> It's quite likely that any such conversion will be just as slow
> as rendering by a PDF viewer.

No you don't see the point. I finaly exported the image in .jpg format
and included it with \includegraphics. Then I can see the difference:
the same image (the resolution is probably much lower but it makes
no difference on A4 paper) the page is rendered as usual in a fraction
of second.

I'll have a look at the external library but I'm sceptik ...

> Bob T.

Thankx.

On Mon, 28 Mar 2011 23:38:15 +0200, GL wrote:
 > Le 28/03/2011 22:25, Bob Tennent a �crit :
 >> On Mon, 28 Mar 2011 20:42:48 +0200, GL wrote:
 >>
 >>   >  When using shadings with different layers Adobe Reader becomes
 >>   >  extremely slow to render the image. For example 2 layers, the first
 >>   >  (foregroup) is quickly displayed while the background is set
 >>   >  about 5 to 10 seconds later !
 >>
 >> Try some other PDF viewers to see whether it's just the Adobe
 >> Reader that is having problems.
 >
 > Yes it's the same for FireFox. TeXWorks does not display the opacity
 > and ghostview neither...

Firefox and TeXWorks are not PDF viewers. If you're on Windows:

http://en.wikipedia.org/wiki/List_of_PDF_software#Viewers_6

 > The problem - IFAIK - is that it's not an image: it's a vector.
 > For an image management software, on intel core i7, this is child play.
 >
 >>   >  Is there a turn around ? Or a possibility to transform the
 >>   >  vectorial image into a bitmap/jpeg/png one ? Preferably
 >>   >  within the compilation...
 >>
 >> It's quite likely that any such conversion will be just as slow
 >> as rendering by a PDF viewer.
 >
 > No you don't see the point. I finaly exported the image in .jpg format

Exported the image from what?  

 > and included it with \includegraphics. Then I can see the difference:
 > the same image (the resolution is probably much lower but it makes
 > no difference on A4 paper) the page is rendered as usual in a fraction
 > of second.

You seem to have an application that can export jpg images. Great. If
you prefer bitmap images to scalable vector graphics, that's what you
should be doing. What does this have to do with tikz or TeX?

Bob T.

On Mar 29, 4:42=A0am, GL <gouail...@gmail.com> wrote:
> I suspect this is because pdf produces vectorial images.
>
> Is there a turn around ? Or a possibility to transform the
> vectorial image into a bitmap/jpeg/png one ? Preferably
> within the compilation...

Without actually trying this myself, I suspect you're right.
Mathematica has (or had? haven't checked the latest version yet) the
same problem when it exported millions of tiny vector patches to
represent a contour or shading.

AFAIK PDF does have some support for vector gradients, but I don't
know how much they help in practise.

Converting the shading itself to a bitmap form would definitely help;
would it be possible to export the shading and the rest of the
graphics separately so the former could be essentially rendered to PNG
while the rest of the vector image was overlaid on top? This is what I
use to get acceptable 3D surface plots from Matlab... (see
matlabfrag.m, written by a friend of mine, for the details)

Cheers,
Will

Le 29/03/2011 11:16, Will Robertson a �crit :
> On Mar 29, 4:42 am, GL<gouail...@gmail.com>  wrote:
>> I suspect this is because pdf produces vectorial images.
>>
>> Is there a turn around ? Or a possibility to transform the
>> vectorial image into a bitmap/jpeg/png one ? Preferably
>> within the compilation...
>
> Without actually trying this myself, I suspect you're right.
> Mathematica has (or had? haven't checked the latest version yet) the
> same problem when it exported millions of tiny vector patches to
> represent a contour or shading.
>
> AFAIK PDF does have some support for vector gradients, but I don't
> know how much they help in practise.

I looked at the pgfmanual: the external library gives an example
page 354

� For example, on my computer, the ImageMagick Suite is installed which
� comes with the convert tool.
I get ImageMagick too it's free. But I've not be able to do the export.
The "example" of the pgfmanual is not finished... difficult to find
the missing parts. Besides windows shell syntax may be different from
Linux.

Just for fun, try with this tikzpicture to see how it is slow:
(pdfLaTeX is required)

% --------------------------------------------------------------
\documentclass [a4paper]{article}
\usepackage [svgnames]{xcolor}
\usepackage {etoolbox,tikz}\usetikzlibrary{shadings,fadings,shapes.symbols}
\pdfpageattr{/Group <</S /Transparency /I true /CS /DeviceRGB>>}% 
Opacity problem with current pgf version...

\begin{document}\makeatletter

\providerobustcmd*\TabU [1][\textcolor{Goldenrod}]{%
     #1{{\fontsize{\sixt@@n\p@}{\sixt@@n\p@}\usefont 
U{eur}mn\char"1C}$_\aleph
                     \mkern.1666mu 
b\,$\rotatebox[origin=c]{-90}{\usefont{T1}{lmss}mn U}}}

\newsavebox\TABUlogo

\setbox\TABUlogo =\hbox{\scalebox 6{\TabU[]}}
\def\tabuscale{1.618}\def\taburot{12}
  \begin{tikzfadingfrompicture}[name=TABUlogo,rotate=\taburot]
      \node at (0,0) [cloud,aspect=2,cloud 
puffs=14,thin,shade,rotate=\taburot,inner color=transparent!20,outer 
color=transparent!80]
 
{\fboxrule\z@\boxframe{\tabuscale\wd\TABUlogo}{2\ht\TABUlogo}{\tabuscale\dp\TABUlogo}};
      \node at (0,0) [cloud,aspect=2,cloud 
puffs=14,thin,shade,rotate=\taburot,shade,shading=color wheel]
 
{\fboxrule\z@\boxframe{\tabuscale\wd\TABUlogo}{\tabuscale\ht\TABUlogo}{\tabuscale\dp\TABUlogo}};
  \end{tikzfadingfrompicture}
  \setbox\TABUlogo=\hbox{\tikz{
        \node [cloud,aspect=2,cloud 
puffs=14,text=DarkGoldenrod,draw=lime,thin,path fading=TABUlogo,fit 
fading=true,rotate=\taburot,shade,shading=color wheel white center]
                  {\copy\TABUlogo};
        \node [cloud,aspect=2,cloud puffs=14,path fading=TABUlogo,fit 
fading=false,shading=color wheel,opaque,rotate=\taburot]
 
{\fboxrule\z@\boxframe{\wd\TABUlogo}{\ht\TABUlogo}{\dp\TABUlogo}};
  }}

\copy\TABUlogo

\end{document}\endinput
% -------------------------------------------------------------

> Converting the shading itself to a bitmap form would definitely help;
> would it be possible to export the shading and the rest of the
> graphics separately so the former could be essentially rendered to PNG
> while the rest of the vector image was overlaid on top? This is what I
> use to get acceptable 3D surface plots from Matlab... (see
> matlabfrag.m, written by a friend of mine, for the details)

Yes ? Do you see a difference in quality if everything is bitmap ?
I mean, jpg compression can render high quality images, without much
loss and conversely with a great improvement in size and performance
to render it...

> Cheers,
> Will

Best regards.

Le 29/03/2011 00:24, Bob Tennent a �crit :
> On Mon, 28 Mar 2011 23:38:15 +0200, GL wrote:
>   >  Le 28/03/2011 22:25, Bob Tennent a �crit :
>   >>  On Mon, 28 Mar 2011 20:42:48 +0200, GL wrote:
>   >>
>   >>    >   When using shadings with different layers Adobe Reader becomes
>   >>    >   extremely slow to render the image. For example 2 layers, the first
>   >>    >   (foregroup) is quickly displayed while the background is set
>   >>    >   about 5 to 10 seconds later !
>   >>
>   >>  Try some other PDF viewers to see whether it's just the Adobe
>   >>  Reader that is having problems.
>   >
>   >  Yes it's the same for FireFox. TeXWorks does not display the opacity
>   >  and ghostview neither...
>
> Firefox and TeXWorks are not PDF viewers. If you're on Windows:

Doch ! TeXWorks is: it's the default with MiKTeX.
And I mistook firefox for foxit reader ... sorry

> http://en.wikipedia.org/wiki/List_of_PDF_software#Viewers_6
>
>   >  The problem - IFAIK - is that it's not an image: it's a vector.
>   >  For an image management software, on intel core i7, this is child play.
>   >
>   >>    >   Is there a turn around ? Or a possibility to transform the
>   >>    >   vectorial image into a bitmap/jpeg/png one ? Preferably
>   >>    >   within the compilation...
>   >>
>   >>  It's quite likely that any such conversion will be just as slow
>   >>  as rendering by a PDF viewer.
>   >
>   >  No you don't see the point. I finaly exported the image in .jpg format
>
> Exported the image from what?
 From the pdf actually. TikZ produces a pdf then I would like to convert
the result in jpeg, bitmap or whatever. ImageMagic can convert any image
format, but for pdf it relays the job to ghostscript and this doesn't
work for me presently (ghostscript fails... don't know why. ghostscript
is not really "user friendly" ;-( )

>   >  and included it with \includegraphics. Then I can see the difference:
>   >  the same image (the resolution is probably much lower but it makes
>   >  no difference on A4 paper) the page is rendered as usual in a fraction
>   >  of second.
>
> You seem to have an application that can export jpg images. Great. If
> you prefer bitmap images to scalable vector graphics, that's what you
> should be doing. What does this have to do with tikz or TeX?

This is in the title of the post: Adobe is terribly slow !

> Bob T.

On Tue, 29 Mar 2011 11:40:52 +0200, GL wrote:
 >>   >>
 >>   >>    >   When using shadings with different layers Adobe Reader becomes
 >>   >>    >   extremely slow to render the image. For example 2 layers, the first
 >>   >>    >   (foregroup) is quickly displayed while the background is set
 >>   >>    >   about 5 to 10 seconds later !
 >>   >>
 > Doch ! TeXWorks is: it's the default with MiKTeX.

Probably calls ghostscript.

 >>   >>  It's quite likely that any such conversion will be just as slow
 >>   >>  as rendering by a PDF viewer.
 >>   >
 >>   >  No you don't see the point. I finaly exported the image in .jpg format
 >>
 >> Exported the image from what?

 >  From the pdf actually. TikZ produces a pdf then I would like to convert
 > the result in jpeg, bitmap or whatever. ImageMagic can convert any image
 > format, but for pdf it relays the job to ghostscript and this doesn't
 > work for me presently (ghostscript fails... don't know why. ghostscript
 > is not really "user friendly" ;-( )

So you *converted* the PDF to jpg. But you've only told us which
conversion program *didn't* work; are you finally going to tell us what
*did* work? Have you tried pdftops (xpdf utility)?

 >>   >  and included it with \includegraphics. Then I can see the difference:
 >>   >  the same image (the resolution is probably much lower but it makes
 >>   >  no difference on A4 paper) the page is rendered as usual in a fraction
 >>   >  of second.
 >>
 >> You seem to have an application that can export jpg images. Great. If
 >> you prefer bitmap images to scalable vector graphics, that's what you
 >> should be doing. What does this have to do with tikz or TeX?
 >
 > This is in the title of the post: Adobe is terribly slow !

The Adobe Reader is *always* slow. Please post a *minimal* example of a
tex file that's problematic. Ensure that all the lines are short enough
that they aren't broken at odd places.

Bob T.

Le 29/03/2011 12:51, Bob Tennent a �crit :
> On Tue, 29 Mar 2011 11:40:52 +0200, GL wrote:
>   >    From the pdf actually. TikZ produces a pdf then I would like to convert
>   >  the result in jpeg, bitmap or whatever. ImageMagic can convert any image
>   >  format, but for pdf it relays the job to ghostscript and this doesn't
>   >  work for me presently (ghostscript fails... don't know why. ghostscript
>   >  is not really "user friendly" ;-( )
>
> So you *converted* the PDF to jpg. But you've only told us which
> conversion program *didn't* work; are you finally going to tell us what
> *did* work? Have you tried pdftops (xpdf utility)?

Yes, there is a "print screen" key on my keyboard ;-)

>   >>    >   and included it with \includegraphics. Then I can see the difference:
>   >>    >   the same image (the resolution is probably much lower but it makes
>   >>    >   no difference on A4 paper) the page is rendered as usual in a fraction
>   >>    >   of second.
>   >>
>   >>  You seem to have an application that can export jpg images. Great. If
>   >>  you prefer bitmap images to scalable vector graphics, that's what you
>   >>  should be doing. What does this have to do with tikz or TeX?
>   >
>   >  This is in the title of the post: Adobe is terribly slow !
>
> The Adobe Reader is *always* slow. Please post a *minimal* example of a
> tex file that's problematic. Ensure that all the lines are short enough
> that they aren't broken at odd places.

See my answer to William Robertson today 11:31.

>
> Bob T.

On Tue, 29 Mar 2011 13:30:10 +0200, GL wrote:
 > Le 29/03/2011 12:51, Bob Tennent a �crit :
 >> On Tue, 29 Mar 2011 11:40:52 +0200, GL wrote:
 >>   >    From the pdf actually. TikZ produces a pdf then I would like to convert
 >>   >  the result in jpeg, bitmap or whatever. ImageMagic can convert any image
 >>   >  format, but for pdf it relays the job to ghostscript and this doesn't
 >>   >  work for me presently (ghostscript fails... don't know why. ghostscript
 >>   >  is not really "user friendly" ;-( )
 >>
 >> So you *converted* the PDF to jpg. But you've only told us which
 >> conversion program *didn't* work; are you finally going to tell us what
 >> *did* work? Have you tried pdftops (xpdf utility)?
 >
 > Yes, there is a "print screen" key on my keyboard ;-)

So after the Adobe Reader rendered the PDF to the screen, you instantly
"exported" a bitmap by taking a screenshot. And you think that
contradicts my suggestion that converting to a bitmap would take as long
as PDF rendering. Sigh.

 >>   >>    >   and included it with \includegraphics. Then I can see the difference:
 >>   >>    >   the same image (the resolution is probably much lower but it makes
 >>   >>    >   no difference on A4 paper) the page is rendered as usual in a fraction
 >>   >>    >   of second.
 >>   >>
 >>   >>  You seem to have an application that can export jpg images. Great. If
 >>   >>  you prefer bitmap images to scalable vector graphics, that's what you
 >>   >>  should be doing. What does this have to do with tikz or TeX?
 >>   >
 >>   >  This is in the title of the post: Adobe is terribly slow !
 >>
 >> The Adobe Reader is *always* slow. Please post a *minimal* example of a
 >> tex file that's problematic. Ensure that all the lines are short enough
 >> that they aren't broken at odd places.
 >
 > See my answer to William Robertson today 11:31.

Please look again at my request for a *minimal* example, with no line
breaks in the middle of commands.

Le 29/03/2011 14:00, Bob Tennent a �crit :
> On Tue, 29 Mar 2011 13:30:10 +0200, GL wrote:
>   >  Le 29/03/2011 12:51, Bob Tennent a �crit :
>   >>  On Tue, 29 Mar 2011 11:40:52 +0200, GL wrote:
>   >>    >      From the pdf actually. TikZ produces a pdf then I would like to convert
>   >>    >   the result in jpeg, bitmap or whatever. ImageMagic can convert any image
>   >>    >   format, but for pdf it relays the job to ghostscript and this doesn't
>   >>    >   work for me presently (ghostscript fails... don't know why. ghostscript
>   >>    >   is not really "user friendly" ;-( )
>   >>
>   >>  So you *converted* the PDF to jpg. But you've only told us which
>   >>  conversion program *didn't* work; are you finally going to tell us what
>   >>  *did* work? Have you tried pdftops (xpdf utility)?
>   >
>   >  Yes, there is a "print screen" key on my keyboard ;-)
>
> So after the Adobe Reader rendered the PDF to the screen, you instantly
> "exported" a bitmap by taking a screenshot. And you think that
> contradicts my suggestion that converting to a bitmap would take as long
> as PDF rendering. Sigh.

???  I don't care about compilation time. I care about the time Adobe
takes to open and display the document.

>   >>  The Adobe Reader is *always* slow. Please post a *minimal* example of a
>   >>  tex file that's problematic. Ensure that all the lines are short enough
>   >>  that they aren't broken at odd places.
>   >
>   >  See my answer to William Robertson today 11:31.
>
> Please look again at my request for a *minimal* example, with no line
> breaks in the middle of commands.

The example is minimal. It's a fact that Adobe is slow when the image
is somewhat "special". In the example there are two layers, otherwise
I don't have the same visual effect...

The example does not contain line breaks. If you have a problem with
copy-pasting it probably comes from you editor...


\documentclass [a4paper]{article}
\usepackage [svgnames]{xcolor}
\usepackage {etoolbox,tikz}\usetikzlibrary{shadings,fadings,shapes.symbols}
\pdfpageattr{/Group <</S /Transparency /I true /CS /DeviceRGB>>}% 
Opacity problem with current pgf version...

\begin{document}\makeatletter

\providerobustcmd*\TabU [1][\textcolor{Goldenrod}]{%
     #1{{\fontsize{\sixt@@n\p@}{\sixt@@n\p@}\usefont 
U{eur}mn\char"1C}$_\aleph
                     \mkern.1666mu 
b\,$\rotatebox[origin=c]{-90}{\usefont{T1}{lmss}mn U}}}

\newsavebox\TABUlogo

\setbox\TABUlogo =\hbox{\scalebox 6{\TabU[]}}
\def\tabuscale{1.618}\def\taburot{12}
  \begin{tikzfadingfrompicture}[name=TABUlogo,rotate=\taburot]
      \node at (0,0) [cloud,aspect=2,cloud 
puffs=14,thin,shade,rotate=\taburot,inner color=transparent!20,outer 
color=transparent!80]

{\fboxrule\z@\boxframe{\tabuscale\wd\TABUlogo}{2\ht\TABUlogo}{\tabuscale\dp\TABUlogo}};
      \node at (0,0) [cloud,aspect=2,cloud 
puffs=14,thin,shade,rotate=\taburot,shade,shading=color wheel]

{\fboxrule\z@\boxframe{\tabuscale\wd\TABUlogo}{\tabuscale\ht\TABUlogo}{\tabuscale\dp\TABUlogo}};
  \end{tikzfadingfrompicture}
  \setbox\TABUlogo=\hbox{\tikz{
        \node [cloud,aspect=2,cloud 
puffs=14,text=DarkGoldenrod,draw=lime,thin,path fading=TABUlogo,fit 
fading=true,rotate=\taburot,shade,shading=color wheel white center]
                  {\copy\TABUlogo};
        \node [cloud,aspect=2,cloud puffs=14,path fading=TABUlogo,fit 
fading=false,shading=color wheel,opaque,rotate=\taburot]

{\fboxrule\z@\boxframe{\wd\TABUlogo}{\ht\TABUlogo}{\dp\TABUlogo}};
  }}

\copy\TABUlogo

\end{document}\endinput

Yours sincerely.

On Tue, 29 Mar 2011 14:35:58 +0200, GL wrote:

 > ???  I don't care about compilation time. I care about the time Adobe
 > takes to open and display the document.

Perhaps you should complain to Adobe?  

 >> Please look again at my request for a *minimal* example, with no line
 >> breaks in the middle of commands.
 >
 > The example is minimal. It's a fact that Adobe is slow when the image
 > is somewhat "special". In the example there are two layers, otherwise
 > I don't have the same visual effect...
 >
 > The example does not contain line breaks. If you have a problem with
 > copy-pasting it probably comes from you editor...

The line breaks are there before any editing. It's a "feature" of many
Windows-based newsgroup clients that they won't allow long lines. After
editing out several line breaks that were confusing tikz (and installing
several libraries that it seems aren't available in TeXlive, I managed
to get your "minimal" example to compile. The Adobe reader rendered it
in about 2 seconds. Other pdf viewers rendered either the letters or the
background but not both.

I suggest you print to file in the Adobe Reader to produce a Postscript
file; then use ps2pdf to convert back to PDF.  

Bob T.

On Mar 29, 7:31=A0pm, GL <gouail...@gmail.com> wrote:
> Just for fun, try with this tikzpicture to see how it is slow:
> (pdfLaTeX is required)

Yikes. Sure is.

> > Converting the shading itself to a bitmap form would definitely help;
> > would it be possible to export the shading and the rest of the
> > graphics separately so the former could be essentially rendered to PNG
> > while the rest of the vector image was overlaid on top? This is what I
> > use to get acceptable 3D surface plots from Matlab... (see
> > matlabfrag.m, written by a friend of mine, for the details)
>
> Yes ? Do you see a difference in quality if everything is bitmap ?
> I mean, jpg compression can render high quality images, without much
> loss and conversely with a great improvement in size and performance
> to render it...

I prefer not to use JPEG due to compression artifacts; PNG is much
better for non-photograph use.

But the idea is that not everything is a bitmap -- only the surface/
gradient objects. Any solid lines (and text, of course) are still
drawn as vectors, and a gradient can be represented in high quality as
a bitmap with relatively small file sizes. (The vector implementation
of the same is simply inefficient at being drawn, I guess.) So I guess
the answer is no -- graphics quality isn't a problem -- and the DPI
can essentially be improved as much as you like for print use, if you
need.

How you could possibly use this approach for PGF, I've no idea :)

Cheers,
Will

On Mar 30, 12:14=A0am, Will Robertson <wsp...@gmail.com> wrote:
> On Mar 29, 7:31=A0pm, GL <gouail...@gmail.com> wrote:
>
> > Just for fun, try with this tikzpicture to see how it is slow:
> > (pdfLaTeX is required)
>
> Yikes. Sure is.

I meant to say that it's also slow in Mac OS X's PDF rendering as
well, not just Adobe's.
If that's a useful data point or not.

W

Le 29/03/2011 15:55, Bob Tennent a �crit :
> On Tue, 29 Mar 2011 14:35:58 +0200, GL wrote:
>
>   >  ???  I don't care about compilation time. I care about the time Adobe
>   >  takes to open and display the document.
>
> Perhaps you should complain to Adobe?

It's not adobe, it's the mathematics of vectorial graphics !

I could complain to late Isaac Newton as well...

>   >>  Please look again at my request for a *minimal* example, with no line
>   >>  breaks in the middle of commands.
>   >
>   >  The example is minimal. It's a fact that Adobe is slow when the image
>   >  is somewhat "special". In the example there are two layers, otherwise
>   >  I don't have the same visual effect...
>   >
>   >  The example does not contain line breaks. If you have a problem with
>   >  copy-pasting it probably comes from you editor...
>
> The line breaks are there before any editing. It's a "feature" of many
> Windows-based newsgroup clients that they won't allow long lines. After
> editing out several line breaks that were confusing tikz (and installing
> several libraries that it seems aren't available in TeXlive, I managed
> to get your "minimal" example to compile. The Adobe reader rendered it
> in about 2 seconds. Other pdf viewers rendered either the letters or the
> background but not both.

Well. For me it's longer, 5 seconds or so. And if you zoom, it's worse.

> I suggest you print to file in the Adobe Reader to produce a Postscript
> file; then use ps2pdf to convert back to PDF.

Hummm.. I can't print in postscript. I've only primoPDF installed.
It's longer than "print screen" and the result is bad.
Besides the final image is a rectangle, and at least I would like the
blank background to be transparent...

I'll give up and leave it like that.

> Bob T.

GL <gouailles@gmail.com> writes:

> Le 29/03/2011 15:55, Bob Tennent a �crit :
>> Perhaps you should complain to Adobe?
>
> It's not adobe, it's the mathematics of vectorial graphics !
>
> I could complain to late Isaac Newton as well...

not that he would listen, not having been involved in the development of
cartesian geometry.

perhaps ren\'e descartes?
-- 
Robin Fairbairns, Cambridge
my address is @cl.cam.ac.uk, regardless of the header.  sorry about that.

Le 29/03/2011 17:04, Robin Fairbairns a �crit :
> GL<gouailles@gmail.com>  writes:
>
>> Le 29/03/2011 15:55, Bob Tennent a �crit :
>>> Perhaps you should complain to Adobe?
>>
>> It's not adobe, it's the mathematics of vectorial graphics !
>>
>> I could complain to late Isaac Newton as well...
>
> not that he would listen, not having been involved in the development of
> cartesian geometry.
>
> perhaps ren\'e descartes?

Sir Isaac Newton PRS (4 January 1643 � 31 March 1727)

Ren� Descartes, n� le 31 mars 1596 et mort � Stockholm dans le palais 
royal de Su�de le 11 f�vrier 1650

Newton was 7 when Ren\'e died... and hopefully Newton used the cartesian
geometry "a little bit" ;-) I would say that he was not much involved
in the development of CTAN, and this was his fault ...

On Tue, 29 Mar 2011 16:53:24 +0200, GL wrote:
 >
 >> I suggest you print to file in the Adobe Reader to produce a Postscript
 >> file; then use ps2pdf to convert back to PDF.
 >
 > Hummm.. I can't print in postscript. 

Just configure a Postscript printer, any model.  

 > It's longer than "print screen" 

You said you didn't care how long it took.

 > and the result is bad.

If you use the Adobe Postscript driver, it should be good.