Re: RtfExternalGraphic.java bug

You can submit a patch on the sourceforge page. Or you can just wait a 
few hours - I figure since the pichgoal and picwgoal code is not quite 
right anyway because of the percentage case, it's reason enough to 
remove them. (That's all the change you want for now, right?) But I want 
to run through my limited set of test cases first before I commit.

-Phil

Koes, Derrick wrote:

> I have not been able to get any images to show using WordPad.  I've always
> had to use MS Word since, at the moment, I don't have openoffice. ;-)
> 
> To rehash picscalex and picscaley show the images correctly.  The problem
> occurs when pichgoal and/or picwgoal are also included.
> 
> How can I get a code change into source?
> 
> Thanks,
> Derrick
> 
> 
> -----Original Message-----
> From: Phil Chu [mailto:[email protected]] 
> Sent: Monday, February 09, 2004 6:13 PM
> To: Koes, Derrick
> Cc: '[email protected]'
> Subject: Re: [jfor-users] RtfExternalGraphic.java bug
> 
> I just checked my oreilly xsl-fo book and  it seems you're right - 
> scaling of images in fo should be done with content-height and/or 
> content-width.
> 
> Also, upon closer inspection, the code outputting pichgoal and picwgoal 
> is inconsistent, with the picscale x/y code, as the latter checks if the 
> target dimension is a percentage while the former doesn't. And if 
> width/height is supposed to be in pixels, that's another potential 
> problem (I'm assuming everything is in twips at this point)
> 
> I have looked at the external-graphics samples (and also the one created 
> by the testdoc target in the build) - the images don't show up for me in 
> wordpad, but they do in openoffice. Unfortunately, I don't have Word, 
> which I suppose is the "ultimate" test.
> 
> -Phil
> 
> Koes, Derrick wrote:
> 
> 
>>Phil,
>>
>>Thanks for the reply.  The code may make logical sense, but the
>>content-height and/or content-width specified in the fo is there to
> 
> "scale"
> 
>>the image.  The height and width correspond to the
>>block-progression-dimension and inline-progression-dimension properties.
>>
>>To me, this means that pichgoal and/or picwgoal should only be output if
> 
> the
> 
>>fo attributes on the external graphic element content-height and/or
>>content-width respectively are present.
>>
>>Have you tried opening images which contain both pichgoal and/or picwgoal
>>and picscalex and picscaley attributes with Microsoft Word or some other
> 
> rtf
> 
>>reader?
>>
>>Try the following test
>>
> 
> \jfor\samples\cocoon\tests\external-graphicexternal-graphic-test-20010816.fo
> 
>>Thanks,
>>Derrick
>>
>>-----Original Message-----
>>From: Phil Chu [mailto:[email protected]] 
>>Sent: Monday, February 09, 2004 2:04 PM
>>To: Koes, Derrick
>>Cc: '[email protected]'
>>Subject: Re: [jfor-users] RtfExternalGraphic.java bug
>>
>>I took a look in the code, and it seems that pichgoal and picwgoal are 
>>only output if the fo file has width/height attributes specified for 
>>fo:external-graphic. And picscaley and picscalex are only output if the 
>>scaling attribute is specified. Offhand, this seems like correct 
>>behavior (but I see in the bug db someone else reported a scaling 
>>problem), but if I'm missing something, let me know.
>>
>>So, I suggest removing either the width/height or scaling attribute from 
>>fo:external-graphic in your fo document, depending on what you want.
>>
>>-Phil
>>
>>Koes, Derrick wrote:
>>
>>
>>
>>>I believe I have found a bug in the RtfExternalGraphic class.
>>>
>>>The writeRtfContentWithException method contains code to write pichgoal 
>>>and/or picwgoal to the rtf file.  However, there is also code to write 
>>>pich and picw and picscaley and picscalex.  Editors such as the 
>>>ubiquitous MS Word first apply the scaling to the pich and picw values.  
>>>In and of itself this is great.  However, it then applies the pichgoal 
>>>and picwgoal.  These are similar to pich and picw, but measured in twips 
>>>rather than pixels.  This results in a thin or small image.
>>>
>>>
>>>
>>>I want to remove the pichgoal and picwgoal code from the file.  How do I 
>>>enter a bug?  Better yet, where can I check in a change if possible?
>>>
>>>Does anyone see a problem with this proposal?
>>>
>>>This electronic transmission is strictly confidential to Smith & Nephew 
>>>and intended solely for the addressee. It may contain information which 
>>>is covered by legal, professional or other privilege. If you are not the 
>>>intended addressee, or someone authorized by the intended addressee to 
>>>receive transmissions on behalf of the addressee, you must not retain, 
>>>disclose in any form, copy or take any action in reliance on this 
>>>transmission. If you have received this transmission in error, please 
>>>notify the sender as soon as possible and destroy this message.
>>>
>>
>>
>>
> 
> 


-- 
Phil Chu
[email protected]
http://www.technicat.com/


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn