Il 06/10/2011 23:53, Julien Rioux ha scritto:
My easy fix would be to query formats and not even try to call
readBB_from_PSFile() unless the file is actually eps or eps.gz. Can I
ask why is this reading of the bounding box done ? Note that it may also
imply unzipping the file and searching for the contained BB, which may
be expensive. So, imagine I have a .odg (or other non-EPS format).
Should we really convert to EPS, then read the BB ?
Any scenario in which I can see the usefulness of this part of code
where the BB is needed to be extracted from the eps file ? On a related
note, this seems all tightly related to EPS. What if we embed a PNG or
PDF image ?
Having the BB allows you to crop the image with less guessing. It
probably has some other use as well. When you load a .png, the
readBB_from_PSFile fails and the BB is obtained from elsewhere (using
converters if I recall, from the last time I checked). When you load
an .odg it also fails, but it tries too hard, even tries to unzip the
file in case it was a eps.gz. So I think you are right that we should
check for the format of the included file, and only when it is an eps
or ps, then we should call readBB_from_PSFile, and when it is not, go
to the fallback. And when readBB_from_PSfile fails, still go to the
fallback.
Let's put it in another way:
1) I just added a return string() into the readBB_from_PSFile(), cleaned
manually the cache, and launched LyX: I can still see on the screen and
on PDF the included EPS with the correct size (and I can see an included
.odg as well for what it matters);
2) when we need to display an .eps on the screen, we use some external
converter to get a bitmap (ImageMagick's convert, I guess); if the
converter detects a bounding box in the EPS, then it will use it to
create a bitmap of the proper size.
I must be missing some piece of the puzzle here. Is this related to DPI
settings and the possibility for the user to crop in cm/mm/in, rather
than pixels ?
T.
