Conversion of pixel to 1/100mm

[Lars.Langhans]

Hi all,

currently, it is not possible to get a length of a well known string in
a well
known font descriptor in a usable unit like 1/100mm.

We try to use such information for automatically adjustments of text box
width/heights in the new report wizard.

At the moment it is only possible to get the size of such string/font
composition as pixels which depends on the background output device.
To get such values, use the interface:

Size com.sun.star.awt.XLayoutConstrains.getPreferredSize();

Due to the fact it is not possible to get access to the background
output device
I plan to add a new interface, like

com::sun::star::awt::Size convertSizeToLogic(com::sun::star::awt::Size
const& aSize, sal_Int16 TargetUnit);

which knows the background output device because it will be implemented
in the
XWindowPeer.
So it is possible to calculate the 'getPreferredSize()' pixels to usable
1/100mm values.

With this new function it is very easy to get the length of a string
with a well
known font descriptor as 1/100mm or any other target unit.

The type TargetUnit is something out of
com::sun::star::util::MeasureUnit. If the TargetUnit is not usable or
convertable the function returns an IllegalArgumentException.


For completeness there will also implement the reverse interface, to convert
size to pixel of a well known target unit, like 1/100mm to pixel.

com::sun::star::awt::Size convertSizeToPixel(com::sun::star::awt::Size
const& aSize, sal_Int16 SourceUnit);

The type SourceUnit is something out of com::sun::star::util::MeasureUnit.


There will also the two interfaces for awt::Point types.

com::sun::star::awt::Point convertPointToLogic( [in]
com::sun::star::awt::Point aPoint, [in] short TargetUnit )
        raises ( com::sun::star::lang::IllegalArgumentException );

com::sun::star::awt::Point convertPointToPixel( [in]
com::sun::star::awt::Point aPoint, [in] short SourceUnit )
        raises ( com::sun::star::lang::IllegalArgumentException );

Any comments/suggestions?

-Lars

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

[Malte Timmermann]

+1 for having such functionality.

But I am not sure if I like to have two functions for the same thing -
Size and Point are basically the same.

So it's just for convenience.

Conclusion might be to have a function using long, instead of
point/size, but having two calls for one size/point conversion is also
not nice.

I don't know - TBD.

Malte.





Lars Langhans wrote, On 07.04.08 11:51:

> Hi all,
>
> currently, it is not possible to get a length of a well known string in
> a well
> known font descriptor in a usable unit like 1/100mm.
>
> We try to use such information for automatically adjustments of text box
> width/heights in the new report wizard.
>
> At the moment it is only possible to get the size of such string/font
> composition as pixels which depends on the background output device.
> To get such values, use the interface:
>
> Size com.sun.star.awt.XLayoutConstrains.getPreferredSize();
>
> Due to the fact it is not possible to get access to the background
> output device
> I plan to add a new interface, like
>
> com::sun::star::awt::Size convertSizeToLogic(com::sun::star::awt::Size
> const& aSize, sal_Int16 TargetUnit);
>
> which knows the background output device because it will be implemented
> in the
> XWindowPeer.
> So it is possible to calculate the 'getPreferredSize()' pixels to usable
> 1/100mm values.
>
> With this new function it is very easy to get the length of a string
> with a well
> known font descriptor as 1/100mm or any other target unit.
>
> The type TargetUnit is something out of
> com::sun::star::util::MeasureUnit. If the TargetUnit is not usable or
> convertable the function returns an IllegalArgumentException.
>
>
> For completeness there will also implement the reverse interface, to convert
> size to pixel of a well known target unit, like 1/100mm to pixel.
>
> com::sun::star::awt::Size convertSizeToPixel(com::sun::star::awt::Size
> const& aSize, sal_Int16 SourceUnit);
>
> The type SourceUnit is something out of com::sun::star::util::MeasureUnit.
>
>
> There will also the two interfaces for awt::Point types.
>
> com::sun::star::awt::Point convertPointToLogic( [in]
> com::sun::star::awt::Point aPoint, [in] short TargetUnit )
>         raises ( com::sun::star::lang::IllegalArgumentException );
>
> com::sun::star::awt::Point convertPointToPixel( [in]
> com::sun::star::awt::Point aPoint, [in] short SourceUnit )
>         raises ( com::sun::star::lang::IllegalArgumentException );
>
> Any comments/suggestions?
>
> -Lars
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interface-discuss-unsubscribe@...
> For additional commands, e-mail: interface-discuss-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

[frank.schoenheit]

Hi Malte,

> But I am not sure if I like to have two functions for the same thing -
> Size and Point are basically the same.

Are they? Only "basically", or also effectively?

That is, I seem to remember (not sure) that in the VCL world, converting
a Point will not yield the same result as converting a Size, at least
not in all cases. There was something with the scaling set at the
device's MapMode, or the offset at the device, or something like this ...

Thus, I suggested to Lars to use different versions for Size and Point
in the UNO API, too. If you say this is not needed, then we should get
rid of it.

Well, perhaps. Finally, it's also a question of convenience, as you say
yourself  ... Having a Point/Size which needs to be converted would be
  Point aPos( getSomePoint() );
  aPos.X = xDevice.convertToPixel( aPos.X, MapUnit );
  aPos.Y = xDevice.convertToPixel( aPos.Y, MapUnit );
as opposed to
  Point aPos( xDevice.convertPointToPixel( getSomePoint(), MapUnit ) );

> Conclusion might be to have a function using long, instead of
> point/size, but having two calls for one size/point conversion is also
> not nice.

Will converting an X-value always yield the same result as converting
the same number as Y-value? That is: If I have, say, a "Size( 100, 100
)", will the converted Size also have width=height?
At least in VCL, where the MapMode can have different Scale values for X
and Y, this would not be the case.

Ciao
Frank

--
- Frank Schönheit, Software Engineer         frank.schoenheit@... -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

[Malte Timmermann]

That's why I said "basically" - the MapMode.

Since UNO AWT API doesn't have support for this at all, I wonder if it's
good to take this into account for something that was intended to be a
conversion "helper" function.

If that method takes the MapMode into account, point/size conversions
are not the same anymore...

Malte.



Frank Schönheit - Sun Microsystems Germany wrote, On 08.04.08 15:27:

> Hi Malte,
>
>> But I am not sure if I like to have two functions for the same thing -
>> Size and Point are basically the same.
>
> Are they? Only "basically", or also effectively?
>
> That is, I seem to remember (not sure) that in the VCL world, converting
> a Point will not yield the same result as converting a Size, at least
> not in all cases. There was something with the scaling set at the
> device's MapMode, or the offset at the device, or something like this ...
>
> Thus, I suggested to Lars to use different versions for Size and Point
> in the UNO API, too. If you say this is not needed, then we should get
> rid of it.
>
> Well, perhaps. Finally, it's also a question of convenience, as you say
> yourself  ... Having a Point/Size which needs to be converted would be
>   Point aPos( getSomePoint() );
>   aPos.X = xDevice.convertToPixel( aPos.X, MapUnit );
>   aPos.Y = xDevice.convertToPixel( aPos.Y, MapUnit );
> as opposed to
>   Point aPos( xDevice.convertPointToPixel( getSomePoint(), MapUnit ) );
>
>> Conclusion might be to have a function using long, instead of
>> point/size, but having two calls for one size/point conversion is also
>> not nice.
>
> Will converting an X-value always yield the same result as converting
> the same number as Y-value? That is: If I have, say, a "Size( 100, 100
> )", will the converted Size also have width=height?
> At least in VCL, where the MapMode can have different Scale values for X
> and Y, this would not be the case.
>
> Ciao
> Frank
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

[frank.schoenheit]

Hi Malte,

> That's why I said "basically" - the MapMode.
>
> Since UNO AWT API doesn't have support for this at all, I wonder if it's
> good to take this into account for something that was intended to be a
> conversion "helper" function.
>
> If that method takes the MapMode into account, point/size conversions
> are not the same anymore...

Okay, so my memory didn't fool me.

Well, given that the interface shall be implemented at the device
implementation (VCLXDevice), and thus has a direct relation to the
underlying VCL OutputDevice, I think we should take the MapMode into
account: Somebody might have manipulated the MapMode of the underlying
device, bypassing UNO. This might or might not be legitimate, but IMO we
need to be prepared for this.

Also, is there a chance we might decide to expose the MapMode to UNO in
the future? Not sure about this ...

Ciao
Frank

--
- Frank Schönheit, Software Engineer         frank.schoenheit@... -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...