texmacs-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Texmacs-dev] gs_to_png broken -- how to fix?


From: Norbert Nemec
Subject: Re: [Texmacs-dev] gs_to_png broken -- how to fix?
Date: Fri, 03 Dec 2010 15:19:28 +0100

Sorry about the overly complicated description. Here is a patch that fixes the 
problem for me. It should not break any working document and -- as I believe -- 
restore the old behavior.


-------- Original-Nachricht --------
> Datum: Fri, 3 Dec 2010 14:56:25 +0100
> Von: Gubinelli Massimiliano <address@hidden>
> An: address@hidden
> Betreff: Re: [Texmacs-dev] gs_to_png broken -- how to fix?

> Hi Norbert,
>   I'm not quite able to follow your description now but the code in Qt  
> is broken with respect positioning of ps images so if you can fix it  
> that would be nice. As a comparison, the X11 code should be considered  
> correct (unless you remark also there some inconsistencies). I think  
> the most important thing is to preserve appearence of old documents  
> (again unless hard arguments are put forward against).
> 
> best
> max
> 
> 
> On 3 déc. 10, at 14:52, Norbert Nemec wrote:
> 
> > Hi there,
> >
> > i just wondered why several old documents that used to work fine do  
> > not properly display the linked EPS images any more. I identified  
> > the problem as an inconsistency in using Ghostscript:
> >
> > The routine gs_image_size uses 'gs -sDEVICE=bbox' to obtain the  
> > image size. This command ignores the bbox saved in the header of the  
> > eps image and instead analyses the contents to find the smallest  
> > rectangle containing the image.
> >
> > Lateron the image is scaled with gs setting the computed resolution  
> > via the '-r' option. In this context, Ghostscript honors the bbox in  
> > the EPS header.
> >
> > The result is that EPS files that contain an empty border within the  
> > specified bounding box around the actual content are displayed  
> > shifted and cropped within TeXmacs.
> >
> > Before trying to fix this inconsistency: what behavior is intended?  
> > Should the specified bbox be honored or should TeXmacs determine the  
> > bbox from the content?
> >
> > Perhaps, the best solution would be to honor an existing bbox and  
> > determine the bbox from the content if none is given within the EPS  
> > file. This may cause problems with EPS files that specify a bad  
> > bbox, but at least it will work correctly with intentionally non- 
> > minimal bbox settings.
> >
> > Opinions?
> >
> > Norbert Nemec
> > -- 
> > Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!
> > Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail
> >
> > _______________________________________________
> > Texmacs-dev mailing list
> > address@hidden
> > http://lists.gnu.org/mailman/listinfo/texmacs-dev
> 
> 
> _______________________________________________
> Texmacs-dev mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/texmacs-dev

-- 
GMX DSL Doppel-Flat ab 19,99 &euro;/mtl.! Jetzt auch mit 
gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl

Attachment: 0001-Fix-eps_to_png-to-read-bbox-from-file.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]