Since these constants are bitfield flags, we define some methods to make
working with them reasonably type safe.
Move the definitions to outdevstate.hxx, since we need the values there,
and that appears to be the "root most" header file.
Also dump TEXT_LAYOUT_BIDI_LTR constant, since it means the same thing
as TEXT_LAYOUT_DEFAULT (ie. 0), and leaving it in causes people to write
weird code thinking that it's a real flag.
Change-Id: Iddab86cd6c78181ceb8caa48e77e1f5a8e526343
Reviewed-on: https://gerrit.libreoffice.org/10676
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
most of length in vcl are calculated in 'long'
but array of X position tend to be in sal_Int32.
As a prep work to be able to support 'double'
as the base type of Device Coordinate, harmonize
the use of 'long' for non-float coordinate.
Change-Id: I7cb33301ff6a5e2c62247b36a4e07e168a58a323
The eventual goal is to make vcl capable of handling a backend
that use double instead of sal_Int32 as its base type
for device coordinate.
Change-Id: I6174f1f4afe00992b95c9163bc21dd54fec98631
the current implementation of CoreText simply dropped the proper
implementation of DrawTextArray, by ignoring DXArray
this very visibly borked the show-non-displayable character
feature of writer.. the bullet representing the 'spaces'
was quite misplaced.
This solve specifically this problem.
More work is needed to bring proper support of DXArray back to CoreText
Conflicts:
vcl/inc/sallayout.hxx
vcl/source/outdev/text.cxx
Change-Id: Idb2cc90d5ffaa8b83f79241cee2d512112d1c3be
GetTextBoundRect() fits different situations than the GetTextWidth() /
GetTextHeight() combination, so make it clear in the documentation.
These are complex enough that people shouldn't read the code just to
understand the difference, and misunderstanding of purpose of each leads
to visually not nice results.
Change-Id: Ida71477cdffbd8290328551bd6ddb4805b96c415
Detect arguments larger than 64 chars passed by value.
Change-Id: I9b0ea9ccb99d115984a26eab67c9cf6afd5f6cae
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>
The name I gave this makes no sense. Basically, this function calls on
the SalGraphics function to copy the area, so really this name is much
more clear.
Change-Id: I842e6f2b81014a8222c39a62c5437bd53d66141c
* Rearranged outdev.cxx functions to better match outdev.hxx layout
* Moved transparency functions from outdev.cxx to transparency.cxx
* Corrected one comment typo in outdev.hxx
* Moved CreateUnoGraphicsList definition to outdev.cxx out of header
* Formatted function declarations in outdev.hxx
Change-Id: I6fda24ae8208ef5ea7b2fe8f59079d48d0af1488
The following functions should be in the Window class, not in
OutputDevice:
+ IsNativeControlSupported
+ HitTestNativeControl
+ DrawNativeControl
+ GetNativeControlRegion
Additionally, moved nativecontrols.cxx to vcl/source/window/ and whilst
we are about it, it turns out that VirtualDevice isn't used by these
functions. Therefore the 'orrible check to for the type of class can be
removed and in fact as VirtualDevice doesn't use it at all then we can
just remove the function and replace it with a call to
IsNativeWidgetEnabled().
Change-Id: Idd0bfb1cba1c2902f7a6d55d258efb38b67fb827
Renamed functions:
+ supportsOperation -> SupportsOperation
For consistency
+ DrawAlphaBitmap -> DrawDeviceAlphaBitmap
I want to make it more clear that these are the functions that call
on mpGraphics to actually draw on the graphics device
Change-Id: Ic4951bfcc0ac0c09fe5b6908dfdf1f699a634265
I have rearrange the various functions of OutputDevice to better group
them in outdev.hxx. Also moved ImplRotatePos and ImplDrawWavePixel into
the OutputDevice class.
Change-Id: I0b384a4d094dffcfb3ee19c29562630cfb3a2167
ImpObjStack uses it's own home-grown stack and stack functions. There
is a function that unwinds the stack, but really it would be better if
we used std::set. In fact, this is better, because the name ImpObjStack
is really not terribly descriptive. I've replaced it with a stack of
OutDevState objects.
Change-Id: I87bdd4340ad77b7ffd9ff176fa5a9ffeac8b8666
All these do is some very, very basic initialization. There is no need
to lazy load the structure, it should be initialized when OutputDevice
is created in the constructor and deinitialized in the destructor.
Change-Id: I780caf4d02e9a2a7d094989cf0bba579493ca98d
