On 14 August 2013 10:49, Miguel de Benito Delgado <
m.debenito.delg...@gmail.com> wrote:
>
> Joris asked me to convert it to C++, and it stopped there.
>>
>
> You wrote it in scheme, I guess? Did you send the patch to savannah?
>
no, in bash.... it was called ps_to_eps, and looked like this:
---
#!/bin/bash
# 1 2 wh 3 4 wh 5 out 6 in
CRC=crc32
CACHE=~/.TeXmacs/system/cache/images
echo crc32 $6
CRC=`$CRC $6 | sed 's/\(.\)/\\1\//g'`
echo $CRC
mkdir -p $CACHE/$CRC
img=$CACHE/$CRC/img_$1x$2_$3x$4.png
EPSFILE=`mktemp -t ps_to_png_tmp.XXXX`
if ! [ -a $img ] ; then
ps2epsi $6 $EPSFILE # This is only needed because at some point
# There was a bug that didn't create correct eps files, and now
# I have some .tm files with wrong ps in them.
gs -dQUIET -dNOPAUSE -dBATCH -dSAFER -sDEVICE=png16m
-dGraphicsAlphaBits=4 -dEPSCrop -g$1"x"$2 -r$3"x"$4 -sOutputFile=$img
$EPSFILE
rm $EPSFILE
fi
ln -s $img $5
--
Primitive, I know.... but it worked pretty well.
For sessions (like R...) filename+width+height won't be good... they are
all the same dimensions, and probably have
similar names. I see that we have MD5 routines in dpxcrypt in Pdf. I could
use that.
> Should I restore that? (And if I add the CRC caching to the C++ source,
>> where's the best place to put it?)
>>
>
> I guess you could start looking around in scalable_image and
> cached_load_picture.
>
>
sure, I'll look.
> Would this CRC caching also cache scaled versions of the images? That is:
> would we still suffer the performance hit of conversion each time the
> canvas scrolls? If yes, could you add width+height to the index of the
> cache?
>
> The scheme above caches all scales of images. One needs to think about
when/how to clean the cache.
Michael
_______________________________________________
Texmacs-dev mailing list
Texmacs-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/texmacs-dev
