Basically reverts the pieces of
21ec9beae29b19b8ec6f0a16fd0e708e4f210208 to make XSpriteCanvas a
XBitmapCanvas again
Otherwise PresenterHelper::loadBitmap is not an XBitmapCanvas
and so VclFactory::createBitmap cannot succeed
Change-Id: I197adf98e915102f383ee050a8ea16d1e41cecf2
and there's a strange stray ifdef in MSAAService.idl
add mode-lines and remove unnecessary headerguard etc
Change-Id: I072960ac073b2c33d7d820e7dbfe02145685d3f3
...and the hack to locally introduce a bogus pupblished forward declaration of
XFormOperations with which this has been worked around in
cf5c36912390b2f6018f57f79085ab1fa88a08d6 "INTEGRATION: CWS dba23b: work around
idlc limitation, which does not allow to refer unpublished interfaces as
optional entities in published services" no longer works in
offapi/type_reference/offapi.idl.
So given FormController is a (deprecated, even) old-style service (i.e., little
more than glorified commentary), the best fix probably is to demote the
problematic optional property to a comment.
Change-Id: Ia38483c817dc1762ba73315abcd4f9f063db3093
DOCX drawingML shapes had wrong position if they had their
CustomShapeGeometry set (e.g. flipped). This wasn't a problem for VML
shapes, as there the shape knows its position, and position was always
set in oox as well, not in writerfilter. However, in case of WPS shapes,
oox created the shape, and previously writerfilter set the position
after-the-fact. This leads to incorrect results if CustomShapeGeometry
is involved. Fix this by passing the position from writerfilter to oox,
and call setPosition() after creation, but before CustomShapeGeometry is
set.
The other problem was that normally writerfilter learns the position of
the shape when relevant token in GraphicImport::lcl_sprm() arrives, but
this happens after OOXMLFastContextHandlerShape::sendShape() needs that
information. Work around this by accessing the PositionHandler directly.
Change-Id: Iced35dc9467ef77c41f1897f124729f686bd045e
as intended by IBM's symphony contribution
and the individual ICLAs of the developers
Found by: V Stuart Foote <VStuart.Foote@utsa.edu>
Change-Id: I47125ff5c9f1ae241132f13b7b3ee2d6fa3cfe9a
FormulaLanguage::XL_ENGLISH is not OOXML, unconditionally using
SymbolsEnglishXL with RID_STRLIST_FUNCTION_NAMES_ENGLISH_OOXML spoils
the grammars of FormulaLanguage::XL_ENGLISH that are not OOXML.
Change-Id: Id885d1c033cd15dc7b11c6490be3a98500027d37
as #foo doesn't work to link to parameters described in the block, use
"\p foo" instead to format it.
Change-Id: Ic9bd59936f872c8f87aba50e87ba788265149832
Reviewed-on: https://gerrit.libreoffice.org/6459
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
- gb_UnoApi_get_target returns the files in INSTDIR
- stop using rdb files from OUTDIR
- remove gb_UnoApi_install
- remove pointless 2nd parameter of gb_UnoApi_UnoApi
- order-only dependency from gb_UnoApi_get_target to
gb_UnoApiHeadersTarget_get_target because INSTDIR .rdb is always outdated
Change-Id: Id418f75e9b38d6fe135b55eca2594c2624bc41cc
...UNOIDL identifiers starting with an underscore, or starting with a lowercase
letter and containing an underscore, are invalid, so occurrences of those as
method parameter names had been changed (even though changing them is strictly
speaking incompatible, but correctness trumps compatibility here).
Change-Id: I1cd2c32ff1486a13bf0218bcb7d3df5fc615ac01
...i.e., only change it to reflect cases where we deliberately became
incompatible, do not change it to reflect compatible changes. This reverts part
of d567671196fccf20a350f3cbf210eef088fa7ce3 "fdo#57490 deprecate
IsSpellCapitalization."
Change-Id: I2ed58a1740cc22ef1ad4fdcbe04c4a0d2ef547bd
Remove the implication that XCanvas IS-A XBitmapCanvas, i.e. one can
access underlying pixels. That's a preparation for display-list based
canvas implementations, and was a rather silly assumption in the first
place.
Also fixes up all client sites.
Change-Id: I7a3d6f68ef46fe94b23cce7759cc0b8b6ca4dae9
Steps
-Add a new character attribute (RES_CHRATR_HIGHLIGHT)
-Get this character attribute via SwFont class just like
background
-If has highlight, then paint that, otherwise paint background
-Extend UNO API
-Implement DOCX export and import filter
Note: By now character highlight can't be set via UI.
It's a next step to add a highlight option.
Change-Id: I7f81e173744bf256891487f898d06dbf372a2f88
Writer core doesn't support this, and this has been a problem for table
cells as well. There the workaround we're using for quite a while is to
do the rotation at a text portion level instead, which results in
reasonable layout for simple cases. Do the same here.
One additional complexity is that the API between oox and writerfilter
is a single UNO shape, we get this property in oox, and we have to
handle it in writerfilter, when the text frame is already attached to
some text. Kill this problem by adding a FrameInteropGrabBag for sw text
frames: it's useful anyway, and then we can pass around this property
inside the grab bag.
Change-Id: Idb5ec83b5cbdde8f29d15b2cebfad24226bb6507
Had been totaly broken by the recent changes. (Which is fine, it is
just an experimental hack anyway, I am not sure whether it will ever
be used in anger. Just a pet peeve of mine, I dislike seeing
libraries, configuration files, resources etc mixed together in one
"program" folder, especially on OS X, where the convention is to have
app-specific dylibs and frameworks in "Frameworks", and resource files
in "Resources". But this is not any requirement as such; there are
apps in the Mac App Store that blatantly "break" this convention.)
Basically, replace uses of gb_PROGRAMDIRNAME and
gb_Package_PROGRAMDIRNAME with more specific LIBO_FOO_FOLDER, which
for normal builds all expand to the same "program" anyway.
Change-Id: I16c2b3351caa00e251e229aafbccb8346042d3c1
Added the new InteropGrabBag property to the OfficeDocument service
and modified the JUnit UNO unit tests for it.
Added specific implementation in the sfx2 module for the SfxBaseModel
class.
Added specific inherited implementations in the sc, sd, starmath and
sw modules for the ScModelObj, SdXImpressDocument, SmModel, and
SwXTextDocument classes.
This new property is intended by now for its usage on preserving OOX's
theming although the aim is to be able to re-create the theming in the
future from saved properties.
It could also be used for preserving other attributes for
interoperability among document formats.
Change-Id: Ia822856293c70ae22911afa794e3e38bcaa31f86
Reviewed-on: https://gerrit.libreoffice.org/6000
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
...via unoidl-write and the new source-format registry provicers, instead of
using idlc to produce .urd files, regmerge to merge them into legacy .rdb files,
and unoidl-write to translate those to new UNOIDL .rdb files.
gb_UnoApi and gb_InternalUnoApi ctors take an additional argument now that is
the path (below $(SRCDIR)) of the source-format registry from which to obtain
UNOIDL entity definitions. It can either be an .idl file (in which case no
*_add_idlfiles calls should be used and the resulting .rdb will contain all the
entities from that one .idl file; used in some tests to conveniently define all
test-specific entities in a single file) or a directory denoting the root of an
.idl file tree (in which case *_add_idlfiles calls specify the entites to
include in the resulting .idl file). (In the first case, the generated .rdb
file needs to depend on that single .idl file, so the gb_UnoApiTarget ctor
contains a dependency on that additional argument, which happens, as a side
effect, to trigger rebuilds in the second, tree-based case when addition/removal
of .idl files in the tree causes updates of directory time-stamps.)
UnoApiPartTarget and all the dependency-tracking logic based on .urd files in
solenv/gbuild/UnoApiTarget.mk is gone. Generation of an .rdb file now depends
on its source registry (see previous paragraph) and all the .idl files specified
with *_add_idlfiles (in the second, tree-based case above).
A consequence of that is that gb_UnoApi_add_idlfile, -_nohdl, and -_noheader all
do the same now. I left them in for now anyway, maybe they become relevant
again when the use of cppumaker is changed to read directly from a source-format
registry instead of going via a .rdb registry.
The legacy tools idlc, regcompare, regmerge, and regview are still contained in
the URE or SDK for now.
cb344cd59e1ddb7c6db66dbd9263b4755969d4ba "Revert 'Looks like idlc resolved
typedefs inside sequence<...>'" is re-reverted as now "the current offapi.rdb is
generated via unoidl-write instead of idlc."
Change-Id: I3d9d92f17326bc9f49dd934c85aab6a17951d06d
This reverts commit 4bcc515356e2a66417e36600bee9402efb2f9ec3, which needs to be
held back until the current offapi.rdb is generated via unoidl-write instead of
idlc.
...obtained from the old .rdb files via "unoidl-read --published". This removes
the need for update-rdb.sh.
Change-Id: I73c0d026af7e27370602f83c61dfa76fc4d17a83
...for checking compatibility with the reference rdbs. unoidl-check is no
longer based on the legacy registry format, but can process all the various new
UNOIDL registry formats. regcompare is still included in the SDK for now.
(gb_UnoApi[Target]_set_reference_rdbfile now takes a non-empty sequence of rdb
files, any necessary dependencies of the final rdf file preceding it just like
it is required on the unoidl-check command line. Also, executing the
unoidl-check now properly depends on those rdb files.)
TODO: unoidl-check is too conservative for now and flags some changes as
incompatible that are not.
Change-Id: I92e4c69403c5e3fcb31707c98c65a2f509592dd4
...from 6ea6a422fbb6279c6fc589e86603a6864273229d
"s/wiki.services.openoffice.org/wiki.openoffice.org/g" which had caused that
offapi.rdb to be broken and effectively empty, silently reducing the
compatibility check against it to check nothing.
Change-Id: Id35d9a7c0b848faf3a9d4458b63e1d5240817c7c
This is to reflect the JDBC specification where invalid column names
result in an SQLException.
(The drivers within LibreOffice are being updated to reflect this new
specification.)
Change-Id: I76cdf9d5d15d55b534b28219b541ff9190365f9d
Reviewed-on: https://gerrit.libreoffice.org/5921
Reviewed-by: Fridrich Strba <fridrich@documentfoundation.org>
Tested-by: Fridrich Strba <fridrich@documentfoundation.org>
