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>
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>
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>
When exporting to PDF a document with a background image on the page.
The image would always be exported as a bitmap at a fix resolution, even
if the original data had vector form (like a pdf or svg).
This ensures that the original vector data is also exported as it is
done with regularly inserted images.
Change-Id: I7f363614ba375e01a4b076c961ce91dae8c2351b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202994
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Use less IUnknown::QueryInterface, and more COMReference::QueryInterface.
No need to use COMReference default ctor in member initializers.
Change-Id: I28cd07d16dc294d598580f353a4ec7efe82bc480
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198040
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
these were skipped in previous runs, since they contain some code behind #if
After inspecting these, it seems like the removals should not cause trouble.
This also shaves off some 140M input
Change-Id: Ie1f57174dd6fec3ba5b0b91eb0688acdc1a8143d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197494
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen@collabora.com>
No need to look up a cairo function dynamically as we know that in
Windows we are using a cairo we build ourselves so we can be sure that
it is has what we want.
There is a TEXT() macro in winnt.h, and we use that (indirectly)
elsewhere, so we can't just undefine it in postwin.h. Thus we can't
initialise a variable calld TEXT using parentheses.
Check USE_HEADLESS_CODE before checking _WIN32 to get the former code
in the CODA-W case and the latter otherwise for Windows.
Change-Id: I8987e3b33d51ea232f8262413d17a50910d8e7b5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197007
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@iki.fi>
Found after running bin/find-unneeded-includes --headersfwd include/vcl/[d-g]*
This shaves off about 150M input
Change-Id: I2b15257451d4b392dca3e5d07f4a443ee653b04c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196395
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen@collabora.com>
aSquare and aCandidateSquare are filled with the output from
GetOutputWidthPixel() and GetOutputHeightPixel(), which both return a
value of type tools::Long. Replaced the use of sal_uLong for aSquare and
aCandidateSquare with tools::Long to match. This is a follow-up patch
that fixes the incorrect use of sal_uInt64 from a previous patch.
Change-Id: I402c9ed6a949f64217b0833b513bf92b1593d62c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195038
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
GetOutputWidthPixel() and GetOutputHeightPixel() both return a value of
type tools::Long, representing an offset width and height in pixels.
Since aSquare and aCandidateSquare multiply these values, it seems
reasonable to use sal_uInt64 here just in case of larger displays.
Change-Id: Idacf8e7c43e884b72699ee1d521d1e0dbf4715a3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194942
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Tested-by: Jenkins
this path is no longer the default for gtk3 where the SDPR renderer is
the default so there:
export DISABLE_SYSTEM_DEPENDENT_PRIMITIVE_RENDERER=1
is needed, though it is still the default for the gen backend, so that
can be used too
Change-Id: If64b7805ee4987ceab5af99decdf755280270e02
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194079
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
There is definitely a better fix for this, we should not need two
different bitmaps and masking and stuff, but this will fix the problem for now.
Mostly revert the following commits:
commit 7278030b92
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Mon Sep 15 16:26:25 2025 +0200
remove unused DrawModeFlags
commit 581c52dad2
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Wed Sep 10 15:08:04 2025 +0200
BitmapAlphaClampFilter is dead since
commit e7b460f919
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Sat Aug 30 15:23:11 2025 +0200
BitmapEx->Bitmap in canvas
Change-Id: Ic5747ce6143a8320f977111c7635bf736a9996d9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193873
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
VclPixelProcessor2D::processPatternFillPrimitive2D and
impBufferDevice were independently calculating the mask rect in
different ways. So move the calculation to the callers.
This only fixed a tiny part of the problems in this bugreport,
it just helps with off-by-one at zoom levels.
Change-Id: I933f5271e31ba79794951a6b1f469fc28094d0a8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192572
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Mike Kaganski