An equation's size lives in the w:sz of its math runs. The import ignored it,
so every equation came in at the 12pt default of the formula editor, and a file
holding equations at three sizes showed all three the same. An equation whose
runs name no size takes the size of the text around it, which the styles and
the document defaults hold.
The export wrote no size at all. It now puts the size on every math run, and in
the control properties of each object, which is where the fraction bar, the
radical sign and the brackets take theirs from. The size travels in the w
namespace, so it goes out for a DOCX only, the way the color of a formula
already does.
Every formula now carries a size of its own on the way out, including one
written in ODF. Such a formula used to leave the size open and took whatever
the text around it had in the reading application. It now keeps the size it is
drawn at here, so both applications show it the same.
Setting the base size means giving each of the fonts that same size. The font
size dialog, the BaseFontHeight property of the model and this import each did
that on their own, so they now share SmFormat::SetBaseSizeAndFonts. The
property used to put the sizes in a copy that a later merge step reads only for
a font the same call has named, so a lone BaseFontHeight left the fonts alone.
Signed-off-by: Gülşah Köse <gulsah.kose@collabora.com>
Change-Id: I18b6c5814a57d8ccb8be5b7bdd357ce76cea024d
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/13297
Reviewed-by: Balázs Varga <balazs.varga@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 582e3fdb6496d9f511dfefc1f716b4ead6cc3797)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211600
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
A bold or italic part of a Word equation came back plain in Writer,
for example a bold x in a fraction or a bold sin, while its color
already survived the import.
Word keeps the style of a math run in the m:sty of its m:rPr (p, b,
i or bi), which the import never read and the export never wrote. A
normal text run cannot have an m:sty, so Word puts its bold and
italic in w:b and w:i instead. When the whole function name is set to
italic, Word keeps that in the m:ctrlPr of the m:func.
Read these on import and write a bold, ital or nitalic command only
where the run differs from the default. Letters are italic and
digits and function names are upright by default in both Word and
StarMath, so a plain formula gets no new command. The export writes
the same elements back. The bold in the m:ctrlPr of a fraction is
not read, because Word draws it on the bar only, and a command
around the fraction would make the terms bold as well.
follow-up for: I4207aab6a363e5f841de58e3f743d9e010609c10
(starmath OOXML: keep the font color of text in a formula)
and Ic13c9e59756806932f61a6fb51e4919a49cdfcd6
(starmath OOXML: keep the color of the lines and signs in a formula)
Change-Id: Ia2172c0d75e59c37a17c8ce51e36a89f25d8565c
Signed-off-by: Balazs Varga <balazs.varga@collabora.com>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/13466
Reviewed-by: Noel Grandin <noel.grandin@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit d6e51e0d41856f4a6c83df3794742742e3ee5dfd)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211443
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
A fraction whose terms are red came back with red terms and a black
bar, and a colored square root came back with a black root sign.
The formula draws these parts itself, so their color is not in the
text. It sits in the m:ctrlPr of the fraction or the root, which
neither filter read.
Read m:ctrlPr on import and keep the color while the parts inside are
read, so the command comes out once around the whole fraction rather
than repeated on the bar and on both terms. An inner color beats an
outer one, which is how the parser treats nested commands. A border box
that Writer does not draw is dropped, and the color it named stays on
the content that is left.
Write m:ctrlPr back on export wherever a node has a color of its own, but
only for a DOCX. A slide or a sheet does not declare the w namespace that
the color needs. The fraction, the brackets, the root, the accent, the
over and underline, the overbrace and underbrace, the border box and the
n-ary operator each have a property element that can hold one.
Added the testMathFractionBarColor unit test.
Signed-off-by: Bayram Çiçek <bayram.cicek@collabora.com>
Change-Id: Ic13c9e59756806932f61a6fb51e4919a49cdfcd6
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/10047
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 568ac1d9bdfc8bd43995dbd3626e73084d4f90d6)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211416
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Steps to reproduce:
1) Write a formula with a color command, such as color red { 1 }.
2) Save the document as DOCX and open it again.
The formula comes back at the default color, and the color command has
gone from its text.
A run is one stretch of text with a single set of formatting. In a
formula each run carries two property elements. The import already read
the math element m:rPr. The font color sits in the text element w:rPr.
The import skipped that one as an unexpected tag, and the export never
wrote it.
Read w:color on import and put a color command around the text of that
run. A color that StarMath has a name for is written with that name, so
a formula written as color red reads the same way after a round trip.
Other colors become hexadecimal digits, which the parser reads only in
upper case. A value of auto leaves the default color in place, and so
does black, which keeps ordinary formulas clean and lets the color
follow a dark document theme.
The braces of a color command hold an expression, and a run holds
whatever text the document put in it. A run of operators is written as a
literal, which is an expression and keeps the color. A run that does not
parse for any other reason keeps no color command, so the formula reads
the way it did before any color was carried over. The import never
writes command text that fails to parse.
On export, write w:color for a run whose node has a color of its own, but
only for a DOCX. A slide or a sheet never declares the w namespace, so the
color stays out of a presentation or a spreadsheet. The tree has been
arranged by then, so a surrounding color command has already reached the
leaf nodes.
The color of the lines and signs a formula draws, such as a fraction
bar, travels elsewhere and is not covered here.
Added the testMathColor and testMathObjectColorOmittedInSlide unit tests.
Signed-off-by: Bayram Çiçek <bayram.cicek@collabora.com>
Change-Id: I4207aab6a363e5f841de58e3f743d9e010609c10
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/10046
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
(cherry picked from commit dfcc0c42df5c774f4087f425cad0af81ecea6b5e)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211415
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
The services that
SmGraphicAccessible::getSupportedServiceNames
claims support for don't actually exist. Stop
implementing XServiceInfo after all.
For the AccessibleContext service, such a one
existed recently until
Change-Id: I77584db1a6452ee3bf0a9fd7188271e4c658ed07
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Sep 2 10:31:59 2026 +0200
[API CHANGE] a11y: Drop com.sun.star.accessibility.AccessibleContext
, but that one would have had to be reported as
"com.sun.star.accessibility.AccessibleContext",
not "css::accessibility::AccessibleContext", so
it was already incorrect before the service
was dropped in the above commit.
Change-Id: Iad0df2b057c2dd4f138cbb0dbc67dc0a7982d37b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210410
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
With the refactoring from previous commits in place, it's
clear that all callers pass a non-null SfxBindings*
param.
Switch the param to a reference, to make that clear
and prepare for further refactoring.
Change-Id: Id9f1487dba4b84860f9afa52ff9ffb4dd7b1d2c6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208387
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
With refactoring from previous commits in place, it's
now clear that all callers pass a non-null
SfxChildWinInfo*. Pass by reference instead to make
that clear, which also allows to drop some null
checks.
Change-Id: I39bfe179c68afecf9b7aa209feb69d33e57e5388
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208371
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Switch the parameter from a pointer to a reference.
The only 2 callers in SfxChildWindow::CreateChildWindow
always pass a non-null param.
Using a reference makes clear that the param is always
non-null and makes clear that those implementations previously
unconditionally dereferencing the pointer were unproblematic.
Change-Id: Ia2b893aac6c94c3b0e1024cc5500da2463bf9996
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208312
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Switch the parameter from a pointer to a reference.
The only 2 callers in SfxChildWindow::CreateChildWindow
always pass a non-null param.
Using a reference makes clear that the param is always
non-null, allows dropping some null checks and makes
clear that those implementations previously unconditionally
dereferencing the pointer were unproblematic.
Change-Id: I6734dfe6fe4fa1cb6aa80f4e67eb69603e8d86fc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208300
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Switch the weld::Entry and weld::TextView handlers
that are called when the text changes due to user
interaction to pass a weld::TextWidget& param
instead of a weld::Entry& and weld::TextView&
one respectively.
Adjust related methods across the code base accordingly.
This unifies the behavior for both of these
weld::TextWidget subclasses and prepares for
deduplicating the logic and moving it to the
common base class in an upcoming commit.
That will also ensure they stay in sync.
(Change also motivated by the fact that their behavior was
differing before
Change-Id: I03d2a13cd84d53d806eb9e363f49c4b6be28d938
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Jul 9 13:08:58 2026 +0200
tdf#130857 weld: Don't signal about programmatic TextView text change
.)
Change-Id: I5572fc88caf577fae9a23a39f1ec4f2179935a99
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207936
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
When a DOCX math formula put an operator and its operand in one run, for
example "-4", the OOXML import quoted the operator as literal text. The
minus then rendered as a short text hyphen (U+002D) in the text font
instead of a full-length minus sign (U+2212) in the math font, so the
two minus signs in a formula like the quadratic formula came out at
different lengths.
The earlier fix that stopped quoting single-character operator runs only
covered runs that held the operator on its own. A run that combined the
operator with its operand still went through the per-character loop in
encloseOrEscapeLiteral, which quoted every operator character.
Keep the standard math operators (+, -, *, /, =, <, >) bare in that loop
too, using the existing isSingleCharMathOperator helper, and drop them
from the delimiter table that does the quoting. A run like "-4" now
imports as the minus operator followed by 4, so StarMath renders it with
the math-font glyph and both minus signs match.
Change-Id: I38ed1a9fb344cc1a44f391e3ce3f097d8f16d09c
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/4681
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 1be656242e4c3cf42ad246bb2a6e30b3df8ce2d1)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207201
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Commit changes automatically done when running
the the UI rules enforcer:
for a in `git ls-files "*.ui"`; do bin/ui-rules-enforcer.py $a; done
Change-Id: I9c9bed95fc30fb1ba66056fc2508d96fa0d778f0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206972
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The expression calculates needed narrow blanks, after wide blanks
were calculated. The calculation assumes narrow blank 1/4th of a
wide blank; the possible result is 0 to 3.
Also: drop the variable for 0.5, used once. The operation here is
"multiply by 2"; using "divide by 0.5" for that is confusing, and
unless there is some rationale behind that (like IEEE-754-specific
details giving different results here), better use simpler form.
In this case, the variable came from commit
074f0ab1d7 (tdf#76296 Import MathML's
<mspace>, 2016-11-15), and back then, it was Fraction; there seems
to be no specific need for division here.
Change-Id: I0260580023af005efb00eaba06ab6497cc269d43
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/1111
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/1169
Reviewed-by: Andras Timar <andras.timar@collabora.com>
(cherry picked from commit ccf247612e1cfaaf7cd53f250f4a2719a10fa524)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206654
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
In the past, weld.hxx used to contain the class
definitions for weld::Widget and all subclasses.
By now, weld::Widget and almost all subclasses have
been moved to separate headers, to make it easier
to keep the overview and to avoid having to
recompile ~all UI code when one class changes.
By now, only weld::Button is left in weld.hxx.
Rename the header to Button.hxx.
Drop weld.hxx includes and instead add Button.hxx
includes (or weld::Button forward declarations) where
weld::Button is used.
(Don't simply replace all weld.hxx includes with
Button.hxx ones, since many of them were for the
use of other widgets that have since been moved
to their own headers.)
Add further includes where needed now that the
(direct or transitive) includes of weld.hxx were removed.
Change-Id: I8ea6201446a418d5e38b46337059dcd517ee29d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205937
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Fixes this build error seen with clang 21 on
Debian testing after
commit 6f81bce807
Date: Wed Jun 3 12:34:28 2026 +0200
loplugin:unusedmethods
:
starmath/inc/mathml/import.hxx:31:17: error: private field 'm_pDocShell' is not used [-Werror,-Wunused-private-field]
31 | SmDocShell* m_pDocShell;
| ^
Change-Id: I6efc86c6894283443989a35e7a51759d8e046efb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205998
Tested-by: Dan Williams <dcbw@libreoffice.org>
Reviewed-by: Dan Williams <dcbw@libreoffice.org>
In the past, weld.hxx used to contain the class
definitions for weld::Widget and all subclasses,
as well as a few helpers.
By now, weld::Widget and almost all subclasses have
been moved to separate headers, to make it easier
to keep the overview and to avoid having to
recompile ~all UI code when anything in weld.hxx
changes.
Move the weld::toId and weld::fromId helpers from
weld.hxx to weldutils.hxx, in preparation of getting
rid of weld.hxx altogether in an upcomcing commit.
Change-Id: I408fe20a74ff104cbfe07bde3105317a1922ff61
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205936
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This makes it easier to keep an overview and reduces
what needs to be recompiled if the class changes in
the future.
Change-Id: Ie8d0aad9bca3e990f78d4ffc006a04b0a8086fd9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205935
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Move the class out of weld.hxx into its own header, in
order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Add missing includes/forward declarations in places
previously depending on transitive includes that
are now dropped.
Change-Id: I3215b358e0fa45ffce08756218c386e1a4d7ebc6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205928
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
These are not needed inside weld.hxx itself. Instead
add the required includes/forward-declarations to those
files actually needing them, instead of relying on the
now dropped ones.
Change-Id: I5e4cea030867d14057b2bdcc2a2a4cd98843651d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205906
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Move the class out of weld.hxx into its own header, in
order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Change-Id: I34876c5bef75e30e758029b0fe5afeecc92d509d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205903
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Move the class out of weld.hxx into its own header and
source file, in order to make it easier to keep an overview
and to avoid having to recompile ~all UI code when the class
is modified.
Change-Id: I91bae842e5b18a83db45de12150c21f75e537fb9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205900
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Move the class out of weld.hxx into its own header, in
order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Adjust includes in files that were implicitly depending
on transitive includes that are no longer present because
the more specific include/weld/Container.hxx is included
further down now instead of include/weld/weld.hxx.
Change-Id: I04e6bb72ce446b746dfdf88b45c7df9d0ccda473
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205899
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
When importing OOXML math formulas, encloseOrEscapeLiteral() quoted
every delimiter character, including standard math operators like =, -,
and +. StarMath then rendered them as text-font glyphs instead of
math-font operators. This caused the equals sign to misalign with the
fraction bar and the minus sign to render as a shorter text hyphen.
Skip quoting for single-character standard math operators (+, -, *, /,
=, <, >) so StarMath treats them as proper operators with correct glyph
selection and alignment.
A bare operator alone inside braces (e.g. rsup {+}) is a StarMath parse
error because the parser expects an operand. Add a safety re-quote in
readOMathArgInElement() for that case, since all its callers wrap the
result in {...}
Change-Id: I22f01a25212d3c030e8104a00418ab1f6bdb2d07
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/3329
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
(cherry picked from commit f2ccbc5a30dbac56b600747af655076d6f7058c2)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205823
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Move the class out of weld.hxx into its own header, in
order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Change-Id: Ide86f35543468a88288a068cc9f89eaf381ac52f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205763
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Move the class out of weld.hxx into its own header, in
order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Change-Id: Ia7bc570fcd463d9adcbcdad070250cec5bc3b949
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205488
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Move the class out of weld.hxx into its own header, in
order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Change-Id: If7cb4403f1861c465f44a1cae4065b0bf8dfad48
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205323
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
- Convert include guards to #pragma once in salhelper, starmath, tools, ucb, and o3tl.
- Kept changes minimal to a small cross-module batch as requested by the easyHack guidance.
- Verified with: container=1 make -j4 o3tl.build salhelper.build starmath.build tools.build ucb.build
Change-Id: Ic047061433985e12be41bdb6463ac4c8e8969ddd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204555
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
Andrea Gelmini