Age | Commit message (Collapse) | Author |
|
since:
commit bbdbe8ea2ef176ef6f08b30b3c18876c2c4f0c22
Date: Fri Feb 3 22:55:54 2023 +0100
tdf#142018 Properly create Pen width if style is COSMETIC
Change-Id: I739932e7bbf427a72bf16a771c20b6bd5596da5f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147041
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I6453058c4af352a3b0e14cbccbc1a67c73cd1426
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146551
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
on modern hardware, these are less efficient than regular alpha
channels.
Also, this greatly simplies the range of stuff that vcl needs to deal
with, which will make the upcoming transparency->alpha patch easier to
deal with.
Enhance vcl::CreateFromData to convert incoming 1-bit data to 8-bit
image.
Change-Id: I35829da750029fe373d0d2911a669d10bab6ad23
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145321
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This reverts commit 1230b88055c7389d2c376c316f91549e4aaef8aa.
Reason for revert:
The reverted commit breaks the files documented in tdf#152435 (some
text is not shown in those .EMF files). The reverted commit would solve
an issue where some text was not clipped correctly, albeit in a naive
way. As it is more important that text is shown rather than some text
having correct clipping, that patch is reverted and I will look for one
that fixes both cases.
Change-Id: I42e85b802b8bf1e77e96f0016cd1d83201047032
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143970
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
do it like this to avoid adding another mapmode and to keep things
"the same" as much as possible
Change-Id: I1965aa545646f2d27b950d6335b2f608c3e4e04b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143475
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
...added with f71606c920a3f78294da745cd9ef1eacde010224 "new loplugin:moveit".
(I came across this code with an upcoming loplugin:constmove that flags
suspicious uses of std::move involving const-qualified types.)
Change-Id: If9c79d9a838fab5efbb55cb89b27b87f7e7ccd76
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142562
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I8a91edb86edd76b70648507f12b18d9e923ab16e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141774
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Tested-by: Jenkins
|
|
EMR_SAVEDC would call UpdateClipRegion which would break the clip region
sometimes before drawing the text causing it to not be clipped
This line was introduced in a i#964 related patch
(https://bz.apache.org/ooo/show_bug.cgi?id=964)
The document in that test seems to render the same and the test file
from the changed test renders the same also before and after this patch
Change-Id: Id515b90efc9e533e18a35030a9a677de4d4ea02d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142272
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
EMR_EXTSELECTCLIPRGN would not factor in WinOrg coordinates which would
give the clip box wrong coordinates causing some graphics to look
chopped in the wrong way.
Change-Id: I4f9a1b1c27fc276d188d0d865991795dab48dce5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142110
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: Id69f3639cb957570c4165150b288397c6e06727e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142324
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I767f464ec666330a2e8e832b6d6f5736a6bef54d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142228
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: If1278f336aaff56a4378dcc1f0f95e0a749b629d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142099
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: If60dfb726ba42bcb96a2d218bb81cb700f4c71f2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141805
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
The reason for the blurry document in tdf#150888 is that the image is
tiny. PPI is 2540 in that image but when using the window bounding box
(96, 81) this results in a very small image that the .odt then scales up
which makes it blurry.
Apart from that, when opening the extracted .wmf in Draw it's also very
small, around 0.04" squared.
Because MM_ANISOTROPICs definition allows for arbritrary scaling, when
an image would be smaller than an inch squared the PPI is scaled down to
either the images width or height. This makes the extracted WMF match
the size of competitor office suites and fix the blur bug without
breaking past tests.
Change-Id: I11eab879848d9308f818708a91fd9eb91fc65200
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141533
Tested-by: Jenkins
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
This is pretty much the same for SoftEdgePrimitive2D as the
change for GlowPrimitive2D, so for more comments please refer
to commit c2d1458723c66c2fd717a112f89f773226adc841
Added suggested change of DoSaveForVisualControl mechanism
Change-Id: I28901e7a0b6e1823000d2aa6a335ce2fd80e6ce3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139585
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Jusify() normalizes the rectangle so both the Width and Height are
positive, without changing the location of the rectangle. It ensures
that the x and y coordinates will be moved to the top left of the
rectangle.
The name is strange, so renaming Justify() to Normalize().
Change-Id: Idbf163e65e52a798e38f785b8961b8042cf0cf2a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137379
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I34de7408553e4ca702cab9aa611c03dc60b9b6a1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138472
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Communicate Kashida insertion positions in an explicit way.
Rest of LibreOffice communicate adjustments to character widths (e.g.
for justification or spacing) using so-called DX array. DX array is an
array of absolute character positions (e.g. DX[n] is the position after
character n from the start of the lines, and its widths is DX[n] -
DX[n-1]).
This DX array is modified also when Kashidas are inserted after a given
character for Arabic justification, by expanding its width. VCL would
use this to know where to insert the Kashidas and how many ones.
But because DX array is used for both widths adjustments and kashida
insertion, this turns out to be a source of bugs since VCL has tosecond
guess the DX array to find which is pure width adjustment and which also
involves Kashida insertion, and the heuristics it uses are fragile.
This change adds a second array of booleans that records where Kashida
is inserted and communicates it all the way from where Kashida insertion
is decoded in Writer and down to VCL layout.
This change passes the Kashida array only when it seems necessary (e.g.
during drawing but not when measuring text since the DX array is enough
in this case). Hopefully no places where Kashida insertion needs to be
passed down were missed.
A couple of glyph and layout flags that were used for old heuristics and
no longer needed and are removed.
This also fixes:
tdf#87731
tdf#106309
tdf#108604
tdf#112849
tdf#114257
tdf#127176
tdf#145647
tdf#146199
Change-Id: I4ed0850ef2fdc3e9143341afac649e7e7d463c39
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138068
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ie091b22bd77d4e1fbff46545bc86c12f1dbafcfe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138171
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
make the plugin more conservative, so we see less false+
(although we also miss some possibilities in the process)
Change-Id: I91b1806271e7f802d7459834ab7bcc569047da3a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137342
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ibc3ed62d5d09d2da9d7866deb21f49340ba71eea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137117
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I2702e716dc669ffbb870d36d060e110288d7a744
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137043
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
CppunitTest_emfio_emf CPPUNIT_TEST_NAME=Test::TestEmfPlusDrawPathWithCustomCap
introduced in 5b21b65572610df88986e700b81f1156aff14f65 "tdf#142770 tdf#143031
EMF+ Implement CustomLineCap" failed for me both in a local master build on
macOS on Apple M1 and in a Linux aarch64 test build of the libreoffice-7.4.0.1
Flathub flatpak (at <https://buildbot.flathub.org/#/builders/21/builds/7749>)
with
> xmltesttools.cxx:195:Assertion
> Test name: (anonymous namespace)::Test::TestEmfPlusDrawPathWithCustomCap
> equality assertion failed
> - Expected: 1423.297394625,1268.98481214025 830.006276132353,558.656004112967
> - Actual : 1423.297394625,1268.98481214025 830.006276132352,558.656004112967
> - In <>, XPath contents of child does not match
As this failed in exactly the same way for rather different builds (Clang vs.
GCC; Apple M1 vs. whatever ARM processor used by <https://flathub.org/builds>),
it smells like the test input might trigger a case where operations can
legitimately produce slightly different floating point results, which would then
cause the test to erroneously fail for some builds.
So I hacked the test input
emfio/qa/cppunit/emf/data/TestEmfPlusDrawPathWithCustomCap.emf slightly, making
the EmfPlusPath's 2nd EmfPlusPointF Y coordinate identical to the 1st one's, so
that the arrow now points west rather than north-west,
> 00000190: 02 10 c0 db 00 00 00 00 00 00 cc ff 08 40 0e 03
> 000001a0: 2c 00 00 00 20 00 00 00 02 10 c0 db 02 00 00 00
> 000001b0: 00 00 00 00 2b b5 05 45 05 54 56 45 d6 66 00 45
> -000001c0: 05 54 56 45 00 01 81 01 15 40 0e 00 10 00 00 00
> +000001c0: 51 23 4d 45 00 01 81 01 15 40 0e 00 10 00 00 00
> 000001d0: 04 00 00 00 0f 00 00 00 0e 00 00 00 14 00 00 00
> 000001e0: 00 00 00 00 10 00 00 00 14 00 00 00
which happens to let the test compute a different polygonstrokearrow/polygon
value now, but which appears to be stable across at least my x86-64 and aarch64
test builds.
And temporarily reverting the non-test (i.e., drawinglayer) parts of
5b21b65572610df88986e700b81f1156aff14f65 would make the test fail with
> xmltesttools.cxx:121:Assertion
> Test name: (anonymous namespace)::Test::TestEmfPlusDrawPathWithCustomCap
> assertion failed
> - Expression: xmlXPathNodeSetGetLength(pXmlNodes) > 0
> - In <>, XPath '/primitive2D/metafile/transform/polygonstrokearrow/polygon' not found
so the test appears to still faithfully check the intended difference in
behavior.
Change-Id: Iec31246dd7666ec764176622ccc4f246eea6e4ba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136896
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I9fae1d259ecdca37a1babac8a8a0e503b2dc0118
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135960
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
With previous implementation, the EMF+ import is calculating
gradient positions wrongly. It is causing warning:
SvgGradientHelper got invalid SvgGradientEntries outside [0.0 .. 1.0]
and the gradient was not displayed at all.
This patch fixes that and gradient is displayed correctly
Change-Id: I6229c516165436d0c7ae187d9eb69b5494da396f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135607
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
look for local variables that can be std::move'd to parameters
off by default, since it doesn't do proper data flow analysis
Change-Id: I3403a0fcffd165bdea6a772528bc53995c5fdb40
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135527
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
With this commit EmfPlusDrawClosedCurve and EmfPlusFillClosedCurve
support was added. There is still missing Filling Mode (it
is always set to Even Odd Alternate:
https://en.wikipedia.org/wiki/Even%E2%80%93odd_rule )
and Tension support for spline bends.
The graphics is displayed as Tension=0.
A value of Tension=0 specifies that the spline is a sequence of straight lines.
As the value increases, the curve becomes more rounded.
For more information, see [SPLINE77] and [PETZOLD].
Change-Id: Ibccfd584e3d55cd0ca8a29da9f450916d56705d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134333
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
With this commit the Miter is properly implemented,
according to [EMF-PLUS] documentation:
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-emfplus/5ef071f3-f503-4f16-b027-7c4bcf2d1d81
The formula for stroke miter limit is described here:
https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/stroke-miterlimit
Change-Id: Ida87063cc045460e61ffae118f64cf133c810dbf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134164
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
EMF+ is allowing different caps and arrows on both ends
It is not possible to implement that with css::drawing::LineCap,
as it is set line endings on both line start and line end.
Additionally when the Dash Pattern is used, the css::drawing::LineCap
is also applied there.
To resolve that limitation, the Cap needs to be implemented
independetly by using PolygonStrokeArrowPrimitive2D, and
the css::drawing::LineCap inside drawinglayer::attribute::LineAttribute
always set to css::drawing::LineCap_BUTT
Change-Id: I4be76e2dbefcb34154a1404c3b57dc4b7f7ada85
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133299
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
If the lines are created with MOVETO, LINETO, LINETO...
then Line Join NONE is applied. As a result the charts are looks ugly,
with the holes inside it.
For example:
https://bugs.documentfoundation.org/attachment.cgi?id=179962
and
https://bugs.documentfoundation.org/attachment.cgi?id=179837
Additinally commit changed default line join style to miter,
as during experimenting with MS Paint and MS Word,
it appear that default Join Style is PS_JOIN_MITER and
Line Cap is Flat/Butter.
The PDF export tests has been updated, as there is less number
of PDF object after using joiners.
The size of the exported tdf145873.pptx to PDF,
was slighltly decreased from 22.8kB to 22.0KB
Change-Id: I131cc3c5e90f827d67d2360eb18167eed6315abb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133624
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
The WmfTest::testStockObject() contained test for the number of
children in the metafile dump. This can be changed when unimplemented
records are implemented.
The problem was revelead while implementing SetPolyFillMode record:
<https://ci.libreoffice.org/job/gerrit_linux_clang_dbgutil/112114/>
xmltesttools.cxx:234:WmfTest::testStockObject
equality assertion failed
- Expected: 42
- Actual : 47
- In <>, XPath '/metafile/push[2]' number of child-nodes is incorrect
Change-Id: I627801b7ac535a2f0c736880d9675f3d0136136a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133353
Tested-by: Jenkins
Reviewed-by: Hossein - <hossein@libreoffice.org>
|
|
Previously when TranfromationMatrix was used with rotation,
the line weight and dashed line shapes were changed.
In worst case if angle was larger than 90 degrees,
the lines just disappear.
This patch fixes that. The line looks exactly after rotation
(with TranfromationMatrix).
The tests were updated (added some additional rotation),
to prove that now it is working correctly.
Change-Id: Ic2382fa8d1b711a6bf06c94b2d0b9da9e7d396f0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133329
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
With previous implementation, empty spaces between dashes
were too long.
Additionally line joints were not working correctly, after
EMF+ reworking: tdf#111486
This commit fixes all these issues and additionally it is
covering it with tests.
Change-Id: I9404e566d2d7d3405ab817268ad9b1f538c200eb
Change-Id: I523f92a928ab592ff175d0d01c1ad1a3bc22e324
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133207
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
* Fix typo
* Improve links
Change-Id: Ie77ec795675bf7497c90620eb44ebb3191c003b1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133067
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
Change-Id: I5707dbda5468256c8d03ac35b43fb54b8b4f3c7a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132991
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
* Add information on dumping drawyinglayer primitives as xml
* Add link to a new tool named limerest on gitlab
Change-Id: I50a0018d9c3063281b2a761d437bb9def0f34bde
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132936
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
This patch fixes tdf#148359 which prevented the display of EMF images
embedded in the rtf files or even loading when loading them directly.
Looking into the problem caused by the cleanup commit
3e7dd04dd8ca1baea4b7918eb7a7080c595c4625, it became visible that
while enums were converted to enum class, there was a cast that
was wrongly ommited:
- sal_uInt16 nStockId = static_cast<sal_uInt8>(nIndex);
+ StockObject nStockId = static_cast<StockObject>(nIndex);
Now, it is re-written as:
StockObject nStockId = static_cast<StockObject>(nIndex & 0xFF);
The symptom was that the StockObject field was mishandled, and thus
the shapes were displayed in white, instead of black.
"Stock Logical Object" is discussed in the MS document for EMF:
* [MS-EMF] v20210625 - pages 44, 45 and 182
A unit test is provided to make sure that the regression does not
happen again. The test can be run by:
make CPPUNIT_TEST_NAME=testStockObject -sr CppunitTest_emfio_wmf
Change-Id: I9a7f1008e92a96d9fb12aeb7bd057af828c1722a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132540
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
This patch fixes problems caused by the cleanup commit
3e7dd04dd8ca1baea4b7918eb7a7080c595c4625 for type and calculation of
FamilyFont and PitchAndFamily enumerations.
FamilyFont enumeration is described in [MS-WMF] v20210625 page 33:
"In a Font Object, when a FamilyFont value is packed into a byte
with a PitchFont Enumeration value, the result is a PitchAndFamily
Object".
Thus, we will use sal_uInt8 as the underlying type for FamilyFont.
The PitchAndFamily is created as shown in [MS-WMF] v20210625 page 96:
[0 1 2 3] 4 5 [6 7]
Family 0 0 Pitch
The values for FamilyFont enumeration are created according to the
[MS-WMF], and the calculations are changed to use '<< 4' and '>> 4'
instead of applying the same shift to the enumeration values.
Change-Id: I4f6df33ed6405589acf89ba2c9223a571cb510b5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132614
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
With previous implementation the clipping restoring with EmfPlusRecordTypeRestore
was implemented wrongly as it is only taken to account
the shape of clipping (state.getClipPolyPolygon) and doesn't
take if clipping was even enabled (state.getClipPolyPolygonActive).
Additionally the changing states should be made by using method:
wmfemfhelper::HandleNewClipRegion() and not directly.
The similar implementation was applied also to EmfPlusRecordTypeGetDC.
Additionally the clipping for
EmfPlusRecordTypeSetClipRect
EmfPlusRecordTypeSetClipPath
EmfPlusRecordTypeSetClipRegion
was fixed, as initially the clipping is disabled (state.getClipPolyPolygonActive)
and the clipping shape is empty (state.getClipPolyPolygon).
It means that combination other than EmfPlusCombineModeReplace,
was not working correctly.
With this implementation, if Clipping is disabled, then treat clip combining
in special way.
Change-Id: I258bda64e8bfdade7f47ffc7518bf04b7340344f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132415
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
Change-Id: Ic84899bf34f98382e6cc1ffc14310b1667279ee2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132214
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
...after 3e7dd04dd8ca1baea4b7918eb7a7080c595c4625 "tdf#145614 Convert #define to
enum and constexpr"
Change-Id: I3ef1d17295e99c040125acd4b03fd5096848a0e5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131630
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
* Converted symbolic constants with #define in mftools.hxx to:
a) 'enum' where facing multiple values of the same category with
similar prefixes, or enums from the [MS-WMF] / [MS-EMF]
b) extracted the underlying integral type from the above documents
c) 'constexpr' where there was a single value
* Where possible, 'enum class' in 'emfio' namespace is used
* Some enums with binary or comparison operations are not converted
MappingMode, TextAlignmentMode, RasterOperations, PenStyle
CharacterSet, ExtTextOutOptions, PitchFont, FamilyFont, WeightFont
Change-Id: I144b2df4722e23d3b0c0aca7880cf603faa80686
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124099
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
As EMR_SETARCDIRECTION record for EMF is now implemented in commit
7b28920382d3820344bfc4075bac98f85e838dba, it is now removed from
the unimplemented list of records for EMF.
Change-Id: Ib2931d339f924e813d243ba503d4b17aab0d6868
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131401
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
|
|
Change-Id: I30206c68ecf1829ba0094e6259b8ed7dc05f2e9a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131103
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
Change-Id: I3459d753a8f655ca34ecf6c25fdfd9655687c6d1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129660
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
the font name isn't a typical semi-standard one so it neither exists nor
has a standard fallback. binary-hack "Roman" to "Arial" which is
conveniently the same length and does have a standard fallback of
"Liberation Sans" which we can add a dependency on via more_fonts
Change-Id: I1d9b8294f67a00a1e5cabe38b71467e66b83aedf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129454
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
See tdf#42949 for motivation
Change-Id: I49a3ce10dee4b03f99156f5b641f69448e1d5617
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128479
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
Change-Id: Ie0867782b0925800cc094f43f8387fb9d1ff0c21
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128272
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
No need to recompile most of LibreOffice, because the --with-fonts
configure flag changed. This preprocessor define is just used by
unit tests anyway.
Change-Id: Ia2eae7d0c74e59e034fdd8513504a34e51ab428e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128197
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
(In each case, the name of the file is obvious from the surrounding
code, so there's no loss in not having CPPUNIT_ASSERT_LESS/GREATER_MESSAGE
available here.)
Change-Id: I5e4e1a30f6389f8b2801648a6179b574727f0859
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128116
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|