Age | Commit message (Collapse) | Author |
|
Commit 574dc1e8ff6ea4214fefd91216fca5146a4ff13e (EMF+ tdf#142995
tdf#142997 tdf#143076 Add alignment support for DrawString, 2021-06-24)
added this test, it seems the result depends on what fonts are
installed, so add some tolerance.
Probably it fails for me (and not on Jenkins) as I have lots of
additional fonts installed, e.g. Arial (and not only Liberation Sans).
Change-Id: Ie93d1f1efe1fbbf1851ad46f33f5f83c8812e6d3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118470
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
The SrcRect could be specified outside of source bitmap.
In such cases the Destination bitmap should be displayed as shifted
(eg. if position is negative), and scaled properly.
Change-Id: Ied6d339703999faaae061802ef6a28e190d5a176
Change-Id: Ia9772ced282684c2c94a261d97d30b53921d6171
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118345
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
With this commit, real size of the text is used to make
proper horizontal alignment. Additionally vertical alignment
is added and fix for Center alignment was applied
Change-Id: I17d9fd7de7f00f5e69f99c5b09061eb6059be67e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117794
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
Change-Id: Icfcb4199dcd755fb20e14a8166571b6d6e763f2e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117671
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
Change-Id: I8bc4ed015dfad4fd99ca8cfce7fca0e7b411edf3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117443
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
Change-Id: I78b05fe3c293494195bdd37c3030147b1f21228e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117148
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
A WMF may have EMF with EMF+ actions embedded. When we read that,
we drop drawing non-EMF+ actions if we use EMF+. But EMF+ actions
are stored as MetaCommentAction in the metafile, and WMF writer
(unlike EMF) writer simply ignores comments. So when writing WMF,
make sure to read non-EMF actions so that something is written.
This is an extension of 295626a0bd39540544b774094a63df23e5376839.
Change-Id: I37355f694fe656b661abe54274ea203934e68151
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117062
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Some of WMF and EMF behaviours are undocumented.
In that case, we are implementing the behaviour, observed in MS Office
or MS Paint.
With this commit the behaviour of import EMF RestoreDC records,
will be the same as for MS Paint and MS Office.
Change-Id: I73b65d14018f2667ffd59daf16ecc6d7ce9c1870
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117052
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
which is a problem since...
commit 33d2cf7008de79106b5da4bba0241aa14d81d88f
Date: Sat Jun 5 19:30:46 2021 +0200
WMF Change the sign of read fields in BITBLT and DIB records
Change-Id: Iea1261a52866d691435f0612f672636009c00355
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117039
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
which has started since...
commit 01ded1e6d362dbcd7148334c6965d6ad00981d4a
Date: Tue Jun 8 23:07:28 2021 +0200
WMF tdf#55058 tdf#142722 Add implementation of BitBlt and StretchBlt
Change-Id: I5bbde55dbd9e239c05544ac4a21e2758770245d2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117038
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
With previous implementation, the RestoreDC index argument was skipped,
and always the last entry was taken.
With this commit the support for reading SaveDC by specific index
was added. The SaveDC/RestoreDC index support was added for
both EMF and WMF, according to [MS-WMF] and [MS-EMF] documentation.
Change-Id: I9b8a1a41462ae01de25ac3c85e453bcd80e05537
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117033
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
With previous implementation, during reading of rectangles
the optimizations were made after reading every single
rectangle. This was causing performance issues, with many
rectangles (eg. 2500 rectangles).
With this commit, the optimization is made after reading all
rectangles. It is improving performance of FILLRGN, PAINTRGN and
EXTSELECTCLIPRGN records.
Change-Id: I1b8b844efddd08e9bf6f6726c3fdf213a629883f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116996
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
With previous implementation, only BitBlt record with 1 bit color depth
was supported and StretchBlt was not implemented at all.
With this commit the support for 1 bit, 24 bit and 32 bit,
for both BitBlt and StretchBlt were added.
Change-Id: I061b2beae8c2f143ddff9c8c8bb64bf52f4cf502
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116873
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
Change-Id: If3334158e6e0ef9bc3aa33656ad0ee45cf460dbb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116827
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
Most of DIB records (DIBCREATEPATTERNBRUSH, STRETCHDIB)
are implemented partially. If the unimplemted feature are inside
WMF, then the whole reading steam is interrupted and nothing
is displayed.
With this commit if DIB record used missing feature,
then the warning is displayed, and the displaying continue.
The fix allows for displaying WMF image from tdf#55058
Change-Id: I6cc88d41486c52a2b1a6ec0b89166460a78ce7d1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116763
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
Additionally the names of variables were improved,
and additional checks were added for unsupported cases
Change-Id: Id84ef1218c5c2a40c8d01f2d40857d892badbb9f
Change-Id: I1b8571d0a627827bc1e67c2bfc6c1932d58c5233
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116744
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
Change-Id: Ia07b8b4c41233c0f66239d2f37833ddecc0dd278
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116640
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I1d58c4093817403caa5f1112b5d4d5a4e638b799
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116618
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
Change-Id: I45e27efbceff76456f6c22a256a5fce1310272c5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116567
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
With this implementation the support for EMF records:
EMR_POLYTEXTOUTA and EMR_POLYTEXTOUTW were added.
Change-Id: I39580d051ae73bed88e04a34d97b797b6d468dc5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116556
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
In previous implementation if BKMode was set to Transparent,
then both Background of Text and Rectangle was not drawn.
It was wrong, and Rectangle should be always drawn.
This commit fix that issue and allows EMF images
exported by LTspice to be rendered correctly under LibreOffice.
Change-Id: I03801d35d92eb2a3fdc175ca1d5b348a2aa30842
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116394
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
With OPAQUE option enabled, the rectangle need to be drawn,
before drawing text.
With CLIPPED option enabled, the text needs to be drawn
only inside rectangle.
In previous implementation, the rectangle read was skipped and
it was not drawn (for OPAQUE).
For CLIPPED the rectangle was read but Clip was not applied
to text drawing
This commit fix that issues, and allow to draw rectangle correctly,
with BGColor (background color), and add support for Text Clipping
according to [MS-WMF] and [MS-EMF] specification.
The fix applied to EMR_EXTTEXTOUTW, EMR_EXTTEXTOUTA and EXTTEXTOUT records
Change-Id: I0f6248bb9465e6d5f797cddb53f058afb0815a2d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116072
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
The issue is caused by floating numbers,
On x86_64 it is:
338.499728160392-445.269903703769
on arm it is:
338.499728160392-445.26990370377
As in test files, we have two ellipses (which are made from small lines),
which points rounds differently on different architectures
Change-Id: I44dd5c7b3b13f3b1680d5a3a8348d6f467cb2f7c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116270
Tested-by: Jenkins
Tested-by: René Engelhard <rene@debian.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
So the issue is caused by floating numbers,
On x86_64 it is:
338.499728160392-445.269903703769
on arm it is:
338.499728160392-445.26990370377
As in test files, we have two ellipses (which are made from small lines),
which points rounds differently on different architectures
Change-Id: I10efe80fea0944cf957e949c8c209c94fd588702
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116234
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
With previous inplementation, the ARC, ARCTO, CHORD and PIE
records were get Start Point and End Point only with
positive values. It was causing display issues.
This patch fix that according to [MS-EMF] specification
Change-Id: Ie1d90a904e840674380b81af0dfe21260374587d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115994
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
The EDGE optimization shouldn't be used for curves,
otherwise strange issues appearing.
Change-Id: Id677fc9002f0f79913ae756f0e456af7c9f7e507
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115984
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
In Metafile specification, if Start Point is the same as End Point,
then the full circle should be drawn.
Unfortunately with previous implementation, if Start Point is the same
as End Point, nothing is drawn.
This patch fixes that and removed EDGES optimizations, which causes
display issues.
Change-Id: I16a1b98f10378d57bed59696db6cc9f228044292
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115891
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
With previous implementation the ARC, ARCTO and CHORD were
not displayed if the corners of rectangle was switched.
With this patch the shapes are always displayed correctly.
Change-Id: Ie8ac7af812298c0b96c3b5af417117784f128ce1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115757
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
Change-Id: I4be77bf074f93fc978e34e5ba4c4693896e4c467
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115645
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
Reviewed-by: Andrea Gelmini <andrea.gelmini@gelma.net>
|
|
Change-Id: I8f995dab566d9fae79d87fe13741b8ea9658b408
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112998
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
Change-Id: I80e05ff2f24f5da2f5c124c0ee1b302a1c8226ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115570
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
Previosly line width was always 1, and changing width do not affect
line.
Change-Id: I462096b915e053fa089e85860f124466b650558a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115497
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
With this commit the ROUNDRECT is able to change line width and
transformation (including rotation) is supported.
Change-Id: Ic303a74adf0fd0dd452353f250a13140603d492e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115429
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
With this commit the rotation support was added
for INTERSECTCLIPRECT.
Before that change rotation was not applied to these CLIP rectangles.
Change-Id: I3da66790e0aeeaaeeb28d2fc30780cba8dbda390
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115102
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
Change-Id: I5d9b76f0ddd2b7f12604f472986dd95976a8b04d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115185
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
Previous implementation of EMR_ELLIPSE, doesn't support rotation
and EMR_ELLIPSE was not work with EMR_BEGINPATH, EMR_ENDPATH and EMR_ABORTPATH
The EMR_BEGINPATH opens path bracket construction.
Once path bracket construction is open, an application can begin specifying records to
define the points that lie in the path. Path bracket construction MUST be closed by an
EMR_ABORTPATH or EMR_ENDPATH record.
With this patch all these issue was resolved for EMR_ELLIPSE
Change-Id: I6d352e0ff0326dd788d43272bf1330fa6c777df4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115101
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
Previous implementation of EMR_RECTANGLE, doesn't support rotation
and EMR_RECTANGLE was not work with EMR_BEGINPATH, EMR_ENDPATH and EMR_ABORTPATH
The EMR_BEGINPATH opens path bracket construction.
Once path bracket construction is open, an application can begin specifying records to
define the points that lie in the path. Path bracket construction MUST be closed by an
EMR_ABORTPATH or EMR_ENDPATH record.
With this patch all these issue was resolved for EMR_RECTANGLE
Change-Id: Ic51442df8905e47c92eed811cc776762c9752af2
Change-Id: I111f183e509f03c0b276a038680f61156b37b235
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115065
Tested-by: Jenkins
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: Idc40ac8bc0adc2f22b4ff140a563d6f63814f2f1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115001
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
...since
<https://github.com/llvm/llvm-project/commit/abf3ca61e3235681f26d0f527b8e2763dd4c0c62>
"[Diagnostics] Restore -Wdeprecated warning when user-declared copy assignment
operator is defined as deleted (PR45634)"
Change-Id: I43ae8a620915ad211a1f21ecf89b6955b7d2faaf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114674
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
So that we have fewer cases to deal with when we transition to
32-bit bitmaps.
(*) rename maMask to maAlphaMask, since now it is only being used
for alpha duties.
(*) drop mbAlpha and mbTransparent to simplify state management,
the only thing we need to check for alpha is if maAlphaMask is
non-empty.
Change-Id: I06252e38e950e846a94b4c2ba8ea763be17801fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111679
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
'make check' now passes for me without pdfium, all relevant tests are
annotated to skip asserts when there is no pdfium anyway.
Change-Id: Ie22a2b3b42d16e72f9d34ada85dee264d79d5155
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114523
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
"format specifies type 'unsigned long' but the argument has type 'sal_uInt16'
(aka 'unsigned short')"
Change-Id: Ie5397be90ccb5678a97e7a3a0987b60b38ece4e5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113874
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Previously, all of the README files have been renamed to README.md
and now, the contents of these files were changed to use Markdown
format. Other than format inconsistency, some README.md files lacked
information about modules, or were out of date. By using LibreOffice
/ OpenOffice wiki and other documentation websites, these files were
updated. Now every README.md file has a title, and some description.
The top-level README.md file is changed to add links to the modules.
The result of processing the Markdown format README.md files can be
seen at: https://docs.libreoffice.org/
Change-Id: Ic3b0c3c064a2498d6a435253b041df010cd7797a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113424
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
Change-Id: I21d600f58174319ce6386de88ab9ac0ad371688b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113612
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
not the total which includes consumed part
Change-Id: I63b01013a31e6a3f1dcfe895c02a4fa049bb8fe6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113560
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
As the visual glitches were resolved with:
https://gerrit.libreoffice.org/c/core/+/113423
It is time for enabling complex clipping.
Change-Id: I12edc88fc9a55c8deedf3d87faeb50cfe0067a01
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113520
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
The EMR_PAINTRGN record paints the specified region by using the brush
currently selected into the playback device context.
After implement support for PAINTRGN record, the reference image
is displayed correctly:
https://sourceforge.net/projects/libuemf/
Change-Id: I761779713d1200e6079ff798e9c3c9aaba57ad4f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113461
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
The EMR_FILLRGN record fills the specified region by using the specified brush.
After deep analyse of [EMF] documentation, it seems that
bounds from RegionDataHeader was treated as first rectangle of
region. As a result whole bounds was treated as the Region.
Change-Id: Ie34877b71292c05a1f17381a6de51aaed2386565
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113423
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
IRC chat:
<quikee[m]> noelgrandin: doesn't adding operator bool to Bitmap
has the same problem as Graphic and the reason why you dropped that
commit 7334034ae93b49fc93b5859a3c047a319d138282
"drop Graphic::operator bool"
<noelgrandin> quikee[m], hmmm, good point
<noelgrandin> maybe I should just drop both operator bool and
operator! in favor of IsEmpty
<quikee[m]> noelgrandin: I don't remember what the problem is I just
remembered we dropped it Graphic :) sure, dropping everything for
IsEmpty is probably the best
Change-Id: Ieae289cda64f0b8d8fdecd5ea9e6f2bb874ff4cd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113163
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ib7a895fba66f8dc9b6501e61631c02694053b7fc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113157
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|