If I understand correctly, -dTextAlphaBits and -dGraphicsAlphaBits control
oversampling. Would this noticeably affect performance / memory usage?
Unlikely...
Also, I just noticed that scalable_image doesn't use the cache, which means
that the system command executes (a lot of times!) every time the canvas
scrolls, a new paragraph is inserted, etc. Just telling
scalable_image::draw to use the image cache fixes this and of course
greatly improves performance.
If the user repeatedly changes the size this will imply a lot of memory
used, but since the cache is periodically cleaned, I think we could live
with it (ideally we would delete the previous instance of the same image
upon rescaling).
Best,
--
Miguel de Benito.
On Mon, Aug 12, 2013 at 5:27 PM, Michael Lachmann <lachm...@eva.mpg.de>wrote:
> 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
>
>
_______________________________________________
Texmacs-dev mailing list
Texmacs-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/texmacs-dev
