I see. The problem difference stems from this function
in src/Plugins/Ghostscript/gs_utilities.cpp
--
static bool
use_converts (url image) {
#if defined(__MINGW__) || defined(__MINGW32__)
(void) image; return false;
#else
// NOTE: determine whether we should use image magick.
// Indeed, EPSCrop unfortunately does not correctly handle
// non trivial offsets of bounding boxes
static bool has_image_magick= exists_in_path ("convert");
int bx1, by1, bx2, by2;
ps_bounding_box (image, bx1, by1, bx2, by2);
return has_image_magick && (bx1 != 0 || by1 != 0);
#endif
}
--
which says to use image_magick when one of the origins of the bounding box
is not 0.
Later, gs_to_png calls either convert or gs depending on the return code.
So, if convert gives better results than gs, why not call that always when
available?
Or, why does gs give worse results than convert?
I found a simple solution, though I think that the behaviour above is quite
inconsistent.
The call to gs in gs_to_png needs an extra parameter:
--
string cmd= gs_prefix ();
cmd << "-dQUIET -dNOPAUSE -dBATCH -dSAFER ";
cmd << "-sDEVICE=png16m -dGraphicsAlphaBits=4 -dTextAlphaBits=4
-dEPSCrop ";
cmd << "-g" << as_string (w) << "x" << as_string (h) << " ";
--
You need -dTextAlphaBits=4 to also have text smoothing.
Michael
On 12 August 2013 16:09, Michael Lachmann <lachm...@eva.mpg.de> wrote:
> Hi!
>
> When I display an image from inside and R session, the result looks
> pixelated.
> I don't think this was always like that.
>
> Look at the attached files. The only difference between them is the
> boundingbox line
> %%BoundingBox: 1 1 504 504
> in the eps. One starts from 0 0, the other from 1 1.
> The 0 0 one (the original one) is inserted pixelated. The 1 1 is inserted
> smoothly.
> (Insert with Insert->Image->Insert Image...)
>
> Why is that?
>
> Can I do something so that eps is always inserted smooth?
>
> Michael
>
>
_______________________________________________
Texmacs-dev mailing list
Texmacs-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/texmacs-dev
