With Tagged PDF on, a paragraph in a language other than the document's
gets /Lang on its structure element. What is anchored in the paragraph
is tagged inside that same element and inherits the attribute, so a
frame's text and its description would be declared the paragraph's
language.
0d2d9e656d87647f904f1a463ed9b879c2bfb10c (tdf#163272 sw: give a
paragraph its own /Lang, 2026-09-21) avoided that by putting no /Lang on
such a paragraph, on a check of one node of a text frame that can cover
several. Its text still carried the language, on a Span, while what was
anchored in it specified none and inherited the document's. In a German
document that declared a shape's English text German. See
https://gerrit.collaboraoffice.com/c/online/+/13117/comment/89a7866d_907a2957/
The paragraph specifies its own language now, and a frame anchored in it
no longer inherits it. A Figure, a Formula and a frame's Division
specify the document's where the paragraph's differs, which is what the
frame's own paragraphs are measured against. A drawing shape's text is
tagged by drawinglayer, which takes the locale of the drawn portions and
specifies it where they agree; such a shape is nested in its anchor
paragraph in Writer and in no such paragraph elsewhere, so there is
nothing to compare against.
A drawing shape's own element specifies the document's language too. svx
anchors it under the anchor paragraph, drawinglayer opens it there, and
it carries the shape's title and description. Without the attribute, a
described shape in a paragraph that specifies one would have its
description declared the paragraph's language, and its text likewise
where the portions disagree.
testParagraphLanguage compared a structure type against a language and
quoted no text, so nothing identified the words affected. It lists every
element holding text or a description now, against the language it
specifies, an entry reading "P de-DE: Ein deutscher Absatz mit einem
Bild."; one specifying none is listed without a language, so correct
inheritance is asserted too. PDFiumPageObject gained getMarkedContentID
to join a page object's text to its element.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I1eecf0b56f09fc6d144894910a9037d89884dd3b
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/13239
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 898a2e1b3a6fc07d7b43315b2f4781b32f1a20d3)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211609
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
An odd-length array will be drawn as one dash spanning the entire path.
The specifications under
https://www.w3.org/TR/svg-strokes/#StrokeDashing state: "If the list has
an odd number of values, then it is repeated to yield an even number of
values. Thus, the rendering behaviour of stroke-array: 5,4,2 is
equivalent to stroke-dasharray: 5,4,2,5,4,2."
Change-Id: I8f233c4cec5c85f5ab1096b032cbb8743715f14d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211062
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
Tested-by: Jenkins
I9431c460cade3d432cb7abf76930e23f8106a7f1 ("tdf#168462 svx: mark the
slide background as an artifact") left page decoration reaching its
/Artifact by a lie: VclMetafileProcessor2D emitted one only for a
background image, and dropped a tag naming NonStructElement, so the
tag claimed to be a Division and an image. Decoration now says so
itself: the artifact decision reads the decorative flag, and the
caller passes NonStructElement and no image and means them. A
background image keeps its own path to an artifact.
isTaggedSdrObject() becomes opensStructureElement(); its comment
still claimed every one of these primitives comes from an SdrObject.
The exported file is unchanged. The one call that goes away with the
old predicate, alternative text on a tag that opens an artifact,
could not reach the file either: setAlternateText writes nothing
without m_bEmitStructure, and checkEmitStructure() is false inside a
NonStructElement. operator== now compares the element and the
decorative flag, which decide what comes out and were not compared.
Letting a master slide's own shapes out as artifacts does not follow
from treating every background as decoration. A background object can
hold tagged children, and a Paragraph begun inside an artifact opens
no marked content at all; tried on testTdf135192, three pieces of its
content came out in no marked-content section. Something narrower has
to tell the two apart.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: Id0fc0d9bee36e8182702d77e9ac9647709a63f68
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/12321
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 9353a1cac3e8056d175acc29dbeecc79ff1cdcd4)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211170
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
drawinglayer/source/tools/emfphelperdata.cxx:771:32: runtime error: load of value 4280295456, which is not a valid value for type 'EmfPlusHatchStyle'
#0 0x7b14dd7d4d02 in emfplushelper::EmfPlusHelperData::EMFPPlusFillPolygon(basegfx::B2DPolyPolygon const&, bool, unsigned int) drawinglayer/source/tools/emfphelperdata.cxx:771:32
#1 0x7b14dd7f903a in emfplushelper::EmfPlusHelperData::processEmfPlusData(SvMemoryStream&, drawinglayer::geometry::ViewInformation2D const&) drawinglayer/source/tools/emfphelperdata.cxx:1776:29
#2 0x7b14dd7c020c in emfplushelper::EmfPlusHelper::processEmfPlusData(SvMemoryStream&, drawinglayer::geometry::ViewInformation2D const&) drawinglayer/source/tools/emfplushelper.cxx:41:14
#3 0x7b14dd932d9d in wmfemfhelper::implInterpretMetafile(GDIMetaFile const&, wmfemfhelper::TargetHolders&, wmfemfhelper::PropertyHolders&, drawinglayer::geometry::ViewInformation2D const&) drawinglayer/source/tools/wmfemfhelper.cxx:2957:43
#4 0x7b14dd919d51 in wmfemfhelper::interpretMetafile(GDIMetaFile const&, drawinglayer::geometry::ViewInformation2D const&) drawinglayer/source/tools/wmfemfhelper.cxx:2993:9
#5 0x7b14dd470d93 in drawinglayer::primitive2d::MetafilePrimitive2D::create2DDecomposition(drawinglayer::geometry::ViewInformation2D const&) const drawinglayer/source/primitive2d/metafileprimitive2d.cxx:42:42
#6 0x7f14fb527e4f in drawinglayer::primitive2d::BufferedDecompositionPrimitive2D::get2DDecomposition(drawinglayer::primitive2d::Primitive2DDecompositionVisitor&, drawinglayer::geometry::ViewInformation2D const&) const drawinglayer/source/primitive2d/BufferedDecompositionPrimitive2D.cxx:90:41
#7 0x7b14dd4727d5 in TestImportWMF drawinglayer/source/primitive2d/metafileprimitive2d.cxx:149:16
so keep the hatch style as the value read from the stream, and an
unknown one then reaches the switch default
Signed-off-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Change-Id: I9725f2f80d3a00fbf82ac5a84cf55b5c071af68b
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/11529
Reviewed-by: Noel Grandin <noel.grandin@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 906c713f2cdd05372db04c1d807d31b1fff5377a)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210589
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Partially reverts a commit that was causing incorrect SVG rendering,
depending on VCL backend. This commit deleted code that translated
clipping rects from view space into device space. It seems like this
change was made intentionally, but it doesn't work correctly, and
reverting it doesn't seem to affect the behavior of the linked bug.
Regression from commit f5b8ec6b3f
Author: Noel Grandin <noelgrandin@gmail.com>
Date: Fri Oct 17 13:25:32 2025 +0200
tdf#168730 impBufferDevice and caller should have the same mask rect
Change-Id: I7c83a5c372557f658df9ece65cbc6c142a4983ec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209070
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Regression from 5707b5dce7
tdf#101083 speed up SVG rendering with pattern fill (2)
This is the same thing I did in
commit 3cbe3a0259
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Mon Jun 14 15:05:59 2021 +0200
tdf#101083 speed up SVG rendering with pattern fill
but cut and paste from the VclPixelProcessor2D to the CairoPixelProcessor2D code.
Which makes this SVG render in reasonable time when using the cairo backend.
We can probably do even better by cutting out the usage of VCL here, but this
is good enough for now.
+ apply the same as af2175bb87
crashtesting: divide by zero
since:
commit 7b807a6b79
Date: Fri Jun 21 12:28:30 2024 +0200
tdf#161086 bitmap location wrong with SVG with an embedded PNG
bodge it by using the requested width/height and not the possibly
zero on fail actual sizes
Change-Id: Ie0e0462e564a568f99d1c5b9c62f71049f71f9b3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208275
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
The font width used to mean the average character width on Windows,
like GDI’s LOGFONT lfWidth. This complicates things cross-platform, and
also DirectWrite does not expose such info.
Drop the whole average character width nonsense and align Windows to
other platforms, keeping the already existing cross-platforms
workarounds for EMF/WMF that are now applied also to Windows.
Change-Id: I750d42ad090bb9d0f776e80609b7a67b8ac38aac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207990
Reviewed-by: Khaled Hosny <khaled@libreoffice.org>
Tested-by: Jenkins
Completes the deprecation of legacy coordinate subsystem naming by
renaming GetOutOffYPixel() and SetOutOffYPixel() to
GetDeviceOriginY() and SetDeviceOriginY() across OutputDevice,
Window, and CoordinateMapper.
This unifies axis naming conventions following previous X-axis
refactoring passes, clarifying that these fields represent the
physical origin offsets of the device rendering canvas.
This patch also moves view transformation logic inline from outdev/map
to CoordinateMapper, and wraps sprawling multi-line logic formulas
across mapping routines to clean up formatting boundaries.
Key changes:
* include/vcl/outdev.hxx / window.hxx: Updated public declarations
to replace GetOutOffYPixel with GetDeviceOriginY.
* vcl/inc/CoordinateMapper.hxx: Migrated view transformation cache State
members and mapping calculation methods into the mapper object.
* Global adjustments: Patched all related coordinate offset reads
and tracking writes throughout desktop, editeng, sc, svx, and vcl.
Change-Id: I28fec54a7f3312cc41ada2de38b26351c0a65527
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203646
Tested-by: Jenkins
Reviewed-by: Dan Williams <dcbw@libreoffice.org>
Rename GetOutOffXPixel() and SetOutOffXPixel() to GetDeviceOriginX()
and SetDeviceOriginX() across OutputDevice, Window, and CoordinateMapper.
The legacy "OutOff" naming convention obscured the difference between
system-level window positioning offsets and internal content scrolling
(SetPixelOffset). The new nomenclature explicitly communicates that
these metrics strictly govern the device coordinate space origin.
This patch focuses strictly on the X-axis coordinate reads and cleans
up duplicated formatting signatures inside the CoordinateMapper header.
Impacted modules:
* include/vcl: Update public declarations in outdev.hxx and window.hxx.
* vcl/inc: Clean up CoordinateMapper.hxx whitespace and scaling hooks.
* Global: Patch dependent pixel coordinate reads across desktop, editeng,
sc, sfx2, svx, and vcl.
Change-Id: I546e1d255887e3b280ff15caca2e27ef10de52d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206509
Reviewed-by: Dan Williams <dcbw@libreoffice.org>
Tested-by: Jenkins
Calc imported Diagrams due to using mainly DrawingLayer
oox import code, but export, even of the unchanged
DomTrees, was missing (just never done). Thus in
versions before this being a Diagram was lost, it
just always was converted to a GroupHierarchy containing
the Shapes that were part of the Diagram.
Added to read the Diagram's name at Import at all for Calc
oox import, set and used now at the created Diagram.
Added to secure/save the DomTrees for the imported
ReplacementGraphic when importing oxx Calc, that was just
also never done, so it could not be exported as unchanged/
original data (and was not, so that was never noticed).
Added complete export of oox Diagram to Calc. This includes
unchanged versions, but also changed/added versions. This
may need more work, but own turn-around works already.
This mainly uses the same ExportContent, but that needed
some adaptions.
Doing this I also changed the ShapeImport of Calc to use
a single oox::drawingml::ShapeExport, before it created
a separate temporary one for every Shape that was imported.
Also added the checkMinimalDataDoms check to Calc oox
export that is already used in the other apps. As always,
there are huge differences in oox im/export for Calc
compared to the other apps, e.g. a completely different
Group ImportContext is used compared to Impress and I have
no idea why that is done.
Signed-off-by: Armin Le Grand (collabora) <Armin.LeGrand@collabora.com>
Change-Id: Ib7c1b73f7f72599f6054d0cf9203f46980eec5cf
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/1887
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Armin Le Grand <armin.legrand@collabora.com>
(cherry picked from commit b1fbe49401e5e4dbe62ff25580ec7252c0376e88)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206019
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
We already did some improvements, but I wanted to clean
this up somewhat. Reason for the needed corrections was
in principle the sqrt()-based general calculation of
the HoldTime in the default implementation of
calculateCombinedHoldCyclesInSeconds. The original idea
was to hold huge data shorter due to memory constraints.
To solve that we added an adapted version to
CairoPixelProcessor2D.
With lessons learned I decided to remove that and
provide a revised general implementation based on linear
scaling of the HoldTime. Based on assuming the seen
huge Bitmap and estimating 20min for it, just create a
factor and multiply with SizeInBytes.
I checked that and it works as intended. It will spare
us from this problem re-occurring with future SDPRs.
NOTE: This still keeps the CairoSDPR-specific avoiding
of buffering of small Bitmaps when these are available
from Bitmap directly. This stays useful and is
Cairo-specific.
Signed-off-by: Armin Le Grand (collabora) <Armin.LeGrand@collabora.com>
Change-Id: I30c7361c6fbfaf0be90be353091cbaf831db5cd2
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/2005
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit a3d3ae5e931a04ff5718382ccffe9f16de336a42)
(cherry picked from commit 7550c6ea0bb82f7574e4b974f8d24bd1662a878b)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205991
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
shows up when running CppunitTest_sc_shapetest
probably from the recent changes here, when calling tryToGetCairoSurface.
Rather than doing explicit cleanup, lets follow the same path used in
include/vcl/cairo.hxx
and pass around a shared_ptr that makes cleanup automatic.
Change-Id: I1bec6f579af182b259cb0edbd86192627e5c61ea
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/1858
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 70966239f816d81cb9dcb208e7c02e08339da28c)
(cherry picked from commit ee2349dba8aa282e30ae65cbf5ffbb27b707e0ec)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205990
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
When isCairoCompatible and we can get cairo_surface_t
directly from Bitmap for small instances (used 160x100
here, can be adapted) use directly. There is no need to
prepare for MipMapping, so spare the
SystemDependentDataHolder buffering for that cases.
For more information, see comments in commit.
Change-Id: Ia9d51a5749124d7001daf2e5355ceec5afccb264
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/1384
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Armin Le Grand <armin.legrand@collabora.com>
(cherry picked from commit 62dbd904fbea0dee4d54f1bb75601af40c6b91c4)
(cherry picked from commit a23e06360e796e1264f40d31c818d3ac3a5a1f54)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205989
Tested-by: Jenkins
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
If we have a really 'big' pixel-based graphic the cost for creating
the mip-map entries is high. If that is the case, force keeping this
entry alive and not getting flushed by using a large number of
seconds. In that case the local MipMap is more important than the
memory kept allocated for fast repaints.
To detect 'big' graphics, compare to an assumed ScreenSize (may also
be fetched from real screen if needed). To react, create a buffer
residing time of one hour (increase if needed).
NOTE: This will increase MemoryFootPrint if isCairoCompatible
is false by holding the local cairo_surface_t in CairoSurfaceHelper
longer than before.
Change-Id: I1cf726f00d459bc0cb19bb1d202e64e010061426
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/1134
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit 2e1b0a51a745e615ed7e2f22666cc4aa4e005451)
(cherry picked from commit c2c58c177ae822906fe2c558546851643fe54247)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205988
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
The tryToGetCairoSurface() path created a new CairoSurfaceHelper on
every call, bypassing the SystemDependentData cache, so mipmap surfaces
were recomputed per tile paint. Move zero-copy into the CairoSurfaceHelper
constructor so all bitmaps go through the caching path.
Also fix estimateUsageInBytes to account for bytes per pixel.
Change-Id: Ie21b12e92b07a43f4b34f13d22b3aeeaf34534ea
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/1105
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Armin Le Grand <armin.legrand@collabora.com>
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Reviewed-by: Noel Grandin <noel.grandin@collabora.com>
(cherry picked from commit 09cad228f400e5dd7f3e06509a35c3c1729c41b9)
(cherry picked from commit ffc9820016c54d3c6d420a778eb8d0886e1cf36b)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205987
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Andrea Gelmini