incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armin Le Grand <Armin.Le.Gr...@me.com>
Subject Re: [PATCH] Fix for #118485#, #108221#, #67705#
Date Mon, 17 Oct 2011 17:00:06 GMT
	Hi Dennis,

On 17.10.2011 17:55, Dennis E. Hamilton wrote:
> Hi Regina,
>
> Thank you for the complete<draw:frame>  markup.  It is clear what is happening
> now.

As Regina wrote, the transformation is applied to the draw:frame, thus 
used for the OLE itself and the fallback representation. The fallback 
representation is a draw:image and thus also transformable (added the 
shear ability for fully guaranteeing this). Thus, if the OLE or the 
fallback representation is used, transformation will be applied as defined.

The text is added to the draw:object-ole only, not to the draw:image 
fallback representation.

There is no cropping yet since a missing cropping was not reported to 
me. In principle it could be added, too. I guess it's too much for 3.4 
now, but please forward and/or write a task describing this for me.

BTW: Cropping has the bug that it does not work (the interaction part, 
not sure about displaying) with rotated shapes currently; when it was 
designed it was completely forgotten that shapes may be rotated/sheared 
(or generally: transformed). There is a task for this somewhere, though.

Not sure if I understood the Win/MSOffice stuff, but please describe the 
(obviously a compatibility) feature in that task we will need for this.

> I think that you can't click on the rendered image because it is the
> <draw:image>  that your build is using as an alternative to the
> <draw:ole-object>.  Presumably that<draw:image>  was made from the rendering
> that was done when the OLE object was embedded and the document saved.  The
> use of the<draw:image>  is expected when the client doesn't recognize/support
> the<draw:ole-object>  or it doesn't have the application required to activate
> the embedded OLE object.  This can happen because the client is not running
> Windows or it is on Windows but the application that served the OLE object is
> not available.  (At one time, Microsoft Office would report the lack of
> application to users and offer to substitute the static image that had been
> retained at the same time, making it then a non-OLE editable image.  I'm not
> clear what happens in current releases of Office.)
>
> The case that concerns me is that the<draw:frame>  transformation has to be
> applicable to all forms of the image or there is some rule for knowing which
> image for the transformation applies to, since it can only be specified once
> for the<draw:frame>.
>
> Also, for cropping/clipping, that is different than scroll bars and such on a
> recognized OLE embedding.  It would apply to the<draw:image>  as well.  This
> happens with .doc and users are unhappy when the .odt version loses the
> cropping, forces shrinking of the full image onto the page, etc., and there is
> no way to fix it.  I think this is partly an ODF problem and also an OO.o
> problem.
>
>   - Dennis
>
> -----Original Message-----
> From: Regina Henschel [mailto:rb.henschel@t-online.de]
> Sent: Monday, October 17, 2011 06:22
> To: ooo-dev@incubator.apache.org
> Subject: Re: [PATCH] Fix for #118485#, #108221#, #67705#
>
> Hi Dennis,
>
> Dennis E. Hamilton schrieb:
>> Regina,
>>
>> That looks good.  Is the<draw:ole-object>   the only child of
>> the<draw:frame>?
>
> No, it has a draw:image element for the replacement graphic.
>>
>> I'm asking because I wonder what is needed in the ODF specification with
>> regard to<draw:frame>   attributes when there are alternative images among
>> the
>> <draw:frame>   children.  E.g., if there were a<draw:ole-object>   and
a
>> <draw:image>   there together.
>
> The full node is:
> <draw:frame draw:name="MeinName" draw:style-name="gr4"
> draw:layer="layout" svg:width="8.889cm" svg:height="6.307cm"
> draw:transform="rotate (0.5235987755982) translate (8.02cm
> 9.642cm)"><draw:object-ole
> draw:class-id="00000000-0000-0000-0000-000000000000"
> xlink:href="./Object 1" xlink:type="simple" xlink:show="embed"
> xlink:actuate="onLoad"><text:p>Dies ist eine
> Beschreibung.</text:p></draw:object-ole><draw:image
> xlink:href="./ObjectReplacements/Object 1" xlink:type="simple"
> xlink:show="embed" xlink:actuate="onLoad"/></draw:frame>
>
> The wrong class-id is likely because my build does not support OLE, that
> is, I cannot activate the object via doubleclick.
>
>>
>> (I also see that cropping doesn't seem to be handled very easily.)
>
> There is no cropping on the frame, but for OLE-objects, which belong to
> ODF, the position of the active part is determined by the scrollbars and
> the grey edges in the activated object. But for real tests I would need
> a build including full OLE feature. I think Armin should tell you about
> cropping.
>
> Kind regards
> Regina
>>
>>    - Dennis
>>
>> -----Original Message-----
>> From: Regina Henschel [mailto:rb.henschel@t-online.de]
>> Sent: Sunday, October 16, 2011 14:42
>> To: ooo-dev@incubator.apache.org
>> Subject: Re: [PATCH] Fix for #118485#, #108221#, #67705#
>>
>> Hi Dennis,
>>
>> Dennis E. Hamilton schrieb:
>>> While attention is on the topic of rendering control for OLE objects,
>>> I have questions:
>>>
>>> How does this modification show up in the ODF XML surrounding the
>>> OLE object (element<draw:ole-object>)?
>>
>> When I test it with a file, where the OLE-object is already inserted,
>> then I see, that the transformation is done in the parent element
>> <draw:frame>   with the draw:transform attribute.
>>
>> Kind regards
>> Regina



Mime
View raw message