The SvtViewOptions class is used to store the state
of windows/dialogs.
So far, SvtViewOptions::SetWindowState and
SvtViewOptions::GetWindowState are string-based
and the callers are responsible for (de)serializing
the vcl::WindowData to/from string.
This will be changed to become the responsibility
of SvtViewOptions in an upcoming commit.
Since unotools is below vcl in the module
dependency chain, it cannot make use of vcl,
i.e. vcl::WindowData couldn't be used there.
Therefore, move SvtViewOptions from unotools
to svtools, which is above vcl in the module
dependencies.
(svtools/README.md summarizes the purpose of the
module as "Tools on the Top of VCL", which seems
an appropriate place for helper code to manage
the state/options for dialogs, tab pages,...)
Change-Id: If849224c35c7ac895659ddb7c17e6d17061d61a4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208124
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
To solve the trade-off between better spacing and less hyphenation,
support hyphenation level and its user interface, the hyphenation
slider, like DTP software do.
Add new paragraph property com::sun::star::text::ParaHyphenationLevel
The hyphenation slider is the basic interface of DTP software to adjust
single (or all) paragraphs using better word spacing (i.e. more
hyphenation) or less hyphenation (i.e. worse word spacing). It allows 1)
to choose the best from the near equally good layouts and 2) to solve an
extreme bad layout (caused by words without hyphenation or other corner
cases).
– 50% hyphenation level means disabled hyphenation, if minimum
and maximum word spacing settings allow to break the line within
words (default interoperability value).
– 100% hyphenation level means using extra hyphenation only if that
results better word spacing in the line, than breaking within words.
– Between 50% and 100% hyphenation level, use extra hyphenation only if
its weighted word spacing is better, than breaking the line between
words (weighting grows with the hyphenation level).
– Between 0% and 50% hyphenation level it means disabled hyphenation
with increased desired and maximum word spacing, depending on the
hyphenation level. At %0, the desired word spacing is enlarged to the
original maximum word spacing, while maximum word spacing is enlarged
by a single space.
For example, the original 4-page unit test document with the default 50%
hyphenation level contains 14 hyphenations. 100% hyphenation level
results in 22 hyphenations, while 0% only results in 8 hyphenations.
– sw/qa/extras/layout/data/tdf167648_minimum.fodt,
sw/qa/extras/layout/data/tdf169168_minimum.fodt: set maximum
word-spacing to 100% from 101% to limit the original unit test only
for minimum letter spacing.
More information: LO/COOL Book & Typography projects:
https://www.numbertext.org/typography/https://www.numbertext.org/book/
Follow-up to commit cf104be5cb "tdf#119908
tdf#166113 cool#15973 sw smart justify: fix DOCX hyphenation",
commit d572576dd6
"tdf#119908 cool#15973 sw smart justify: fix "smart" hyphenation",
commit 529755f091
"tdf#166113 sw smart justify: adjust algorithm for interoperability" and
commit 7d08767b89 "tdf#130088 tdf#119908
smart justify: fix DOCX line count + compat opt."
Change-Id: I84b3893ea6c5cd4eff74a73514722285e7071392
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207545
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: Jenkins
and
cid#1691453 Variable copied when it could be moved
cid#1691456 Variable copied when it could be moved
cid#1691457 Variable copied when it could be moved
cid#1691449 Variable copied when it could be moved
Change-Id: I7d72e19a177f818dafb7350995cc602c2dd9f52e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203566
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Sets default numbering format of subdocuments to be 012_ABC rather than
previous ABC12, which allows for formatting.
1. Introduces a class `PaddedSequentialTokens` to "pad" the number
with leading zeroes
2. Introduces a function `concatFunc` in parameters to customize
format of numbered subdocuments
Change-Id: I95aaf552189a5e1b9bdf7a178cbc3a83c8ab8e16
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/187939
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Tested-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Add new minimum character limit paragraph property to limit
hyphenation left to the compound constituent boundaries:
com::sun::star::text::ParaHyphenationCompoundMinTrailingChars
– With the previous option for the hyphenation right to the
constituent boundary, this new option allow to limit or disable
hyphenation completely inside the compound constituents, or
hyphenate only at constituent boundaries, with or without
inside the suffix of the word or constituents;
– xmloff: add "no-limit" to loext:hyphenation-compound-push-char-count
and loext:hyphenation-compound-push-char-count;
– "no-limit" values of this and the *LeadingChars option mean
a maximum value. When both *LeadingChars and *TrailingChars
got "no-limit", hyphenation before and inside the suffixes are
forbidden, i.e. it is allowed only at constituent boundaries;
– textflowpage.ui: set max character count to 99, in both options;
– fix ParaHyphenationCompoundMinLeadingChars implementation for
compound words with multiple constituents, when the middle word(s)
are shorter, than the limit (e.g. Hungarian "tűz|kő|pattintás"
wasn't hyphenated as "tűzkő-pattintás", only as "tűz-kőpattintás").
Follow-up to commit 3a332d9f1c
"tdf#158885 cui offapi sw xmloff: fix hyphenation at stem boundary"
and commit c899d3608d
"tdf#158885 sw: don't hyphenate right after a stem boundary".
Change-Id: I0b71562727332217364f9ace85e8ac6ea3abc8b1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196345
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: Jenkins
utl::MediaDescriptor was just a SequenceAsHashMap with a few added
methods. It made it more difficult to assign a SequenceAsHashMap to
MediaDescriptor, without real upsides. In many places, the class was
used not as media descriptor, but just as helper to create sequences.
This change puts the string constants and the former methods into a
namespace utl::MediaDescriptor.
It would be also good to drop comphelper::NamedValueCollection, which
is basically a twin of comphelper::SequenceAsHashMap (TODO).
Change-Id: Ia9b69c5a2ad153ecc654944c419c1880252ed86e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195163
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
This fixes a 7.5 regression from
commit ab0adac692
Fix everything using XCharacterClassification::getStringType()...
Prior to erack's commit, all of the character-type-flags were grouped
together. So it could be a mix of UPPER, LOWER, and TITLE_CASE.
IsUpper returned true if there was at least one UPPER and no LOWER.
return (nFlags & KCharacterType::UPPER)
&& !(nFlags & KCharacterType::LOWER);
Since it was a group of flags, any characters that were non-case
(like a fullstop) did not affect the result of IsUpper.
But when it was changed in 7.5 to
return aCC.isUpper( rText, nPos, nLen );
now every character needed to be considered to be upper-case,
even if it was a non-case character.
So this patch changes the logic back to the original state
(more or less).
The fly in the ointment are any Unicode characters
that would be considered to be TITLE_CASE.
Previously they were ignored (i.e. they didn't affect the outcome),
but now I consider them to be non-uppercase.
That seems to me to be the intent here anyway,
so probably this implementation "fixes a bug"
when a word consisted of a mixture of UPPER and TITLE_CASE chars.
See the first patchset where I added a dummy parameter
to ensure that this was still the only place
using erack's new function.
This proves it is safe to change the logic back,
since this is the only place IsUpper is called.
Change-Id: I7cf1d68bc3eb0a1a468da9e67ab54d1148f097aa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/187934
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
It's unclear to me what these
//==== internal =========================================================
comments are trying to say.
(What does it mean if the public ctor of a class that
gets called from outside that class is "internal"?)
If those were intended to say what methods are internal to a class
then access specifiers (private, protected, public) would be the proper
way to specify what is internal to a class (but that doesn't seem to
be the semantic used here).
If "internal" is meant to indicate that these are LibreOffice-internal
(not available for third-party code in extensions or
macros), then there is no need to explicitly mention that, because
all a11y class implementations are internal only, no instances are
created directly by calling ctors from third party code.)
Change-Id: I118c7e0bee77cda68e67f0a3bfe134aeaaa86d73
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186746
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
separately from all private info files during save.
The new expert config option name is: RemoveEditingTimeOnSaving
(There wasn't any UI element added for this expert config option.)
Change-Id: Iab69d062d161ef6aee1c3eb87ada1c16f8b4fd41
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/184789
Tested-by: Jenkins
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
When calling an Export dialog (PDF, epub, ...) the following
folder will be preselected:
For stored documents:
* Current document directory
* If another directory was chosen for the export,
that directory will be preselected for subsequent exports
(stored only during runtime - per document)
For unstored documents:
* The last used export directory is restored (last used in unsaved doc)
Change-Id: I97595d164cf1d3604166c38aa2a5ed31be56f113
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/184062
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
Tested-by: Jenkins
Add new hyphenation options to adjust hyphenation, like DTP software do
in accordance with typographic requirements:
– Paragraph/Column/Page/Spread end zone spin boxes to Hyphenate Across
section of Text Flow pane of paragraph settings;
– loext:hyphenation-zone-always, loext:hyphenation-zone-column,
loext:hyphenation-zone-page and loext:hyphenation-zone-spread
ODF extensions;
– widorp.cxx, guess.cxx: handle Column/Page/Spread end zones;
– guess.cxx: handle Paragraph end zone (without portions, yet).
According to their typography, languages with long words need better
adjustment of line break of the last full paragraph/column/page/spread
lines, than simply disabling hyphenation by the recent ODF hyphenation-
keep or its equivalent MS Word OOXML extension. DTP software use
paragraph and column/page/spread end zones to adjust the hyphenation
zones in the last lines, for example, setting Column end zone to the
150% percent of the Hyphenation zone, resulting less hyphenation, also
less short words parts at the end of the columns, pages and spreads,
increasing readability.
Note: the default OOXML hyphenation zone 18 pt (or its MS Word variants,
for example 21.25 pt) disables single letter or narrow 2-letter (li-,
fi-, i.e. fi ligature) hyphenations at 12 pt font height. Setting 27 pt
for Column end zone, all 2-letter hyphenation is disabled in last lines
of columns and pages.
Note: textflow.ui needs multiple adjustment definitions for correct work
of the multiple spin boxes.
Change-Id: I37bbb4da30de0ec75eb8636f70d8e16588c56ed1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183565
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
Introduce a new set of setting under org.openoffice.Office.UI/FilePicker
to control whether the settings dialogs of filters always appears. Add an
"Edit Filter Settings" checkbox to the File Open dialog, using the new API
constant FILEOPEN_READONLY_VERSION_FILTEROPTIONS (TemplateDescription.idl)
to show additional controls: "Read Only", "Filter Options", and "Version"
listbox.
Modify the Calc's Text Import filter settings dialog to include an "Always
Show on Import" checkbox.
Co-authored-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: Ic7bea0036ae2db8f8ab223f48499fb0cc8b18425
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183055
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
cache LocaleDataWrapper because otherwise we spend quite a bit of
time doing function-pointer-symbol lookups.
Change-Id: Ic1bd07dabac95a2e1bdad70cffbc2b4cabdc62ed
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183221
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
ODF 1.0 feature hyphenation-keep, i.e. disabling hyphenation across
page etc. was implemented by shifting the full hyphenated line
(fixing also the DOCX layout interoperability, when value of the
useWord2013TrackBottomHyphenation MSO DOCX compatibility option is
true). To shift only the last word, add UNO paragraph property
com::sun::star::text::ParagraphHyphenationKeepLine
and the associated layout in Writer core, i.e. disabling
the hyphenation in the last line, instead of line shifting,
if the value of ParagraphHyphenationKeepLine is true.
Fix missing DOCX layout interoperability by mapping the unhandled
useWord2013TrackBottomHyphenation = false case to the new layout.
Note: shifting lines may be better for languages with long
words, but only with 1) typesetting with line-level (greedy)
line breaking instead of the desirable paragraph-level, 2) and
with missing optimized hyphenation at boundaries of compound word
constituents, and 3) forgotting the following: Shifting only words
or word constituents are better for 1) equal line count on pages
and spreads (very basic typographical requirement), 2) disabling
hyphenation really (shifting doesn't guarantee this, because
shifting is limited in a single line, but the previous line can be
hyphenated, too) and 3) more compact typesetting.
Both hyphenation-keep algorithms are important for interoperability,
but the new HyphenationKeepLine can create state-of-the-art automatic
typesetting with the planned improvements.
Follow-up to commit 9574a62add
"tdf#132599 cui offapi sw xmloff: implement hyphenate-keep".
and commit c8ee0e8f58
"tdf160518 DOCX: import hyphenation-keep to fix layout".
Change-Id: Iafa352ec91bbd5d1d227b8480337fa2b9acb5993
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/181954
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: Jenkins
Currently the document themes are hardcoded and the new ones will
be only used in the current document. This is the first of the
series to make document theme user defined and stored in the user
and shared folders (just like other resources). This change adds
the configuration of the folder which will be used to search for
the document themes. By default the folders are located in the user
and shared profile folders.
Change-Id: I1388983804d012cd7f8575dfc96830451821f56e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180379
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
I think I managed to disable this when I converted it to
use the shared plugin infrastructure.
So fix that, and then make it much smarter to avoid various
false positives.
Change-Id: I0a4657cff3b40a00434924bf764d024dbfd7d5b3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176646
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Switch css::accessibility::AccessibleRelationType
from integer constants to an enum.
This provides more type safety and improves the debugging
experience, e.g. GDB now prints
com::sun::star::accessibility::AccessibleRelationType::AccessibleRelationType_CONTENT_FLOWS_TO
instead of just "2" when printing the value of a
corresponding variable, so it's no longer necessary
to manually look up what constant has that integer
value to know what relation this refers to.
offapi/com/sun/star/accessibility/AccessibleRelationType.idl
had this comment:
> <p>We are using constants instead of a more typesafe enum. The reason
> for this is that IDL enums may not be extended. Therefore, in order to
> include future extensions to the set of roles we have to use constants
> here.</p>
However, the a11y UNO API is internal (not published),
so that shouldn't be a concern.
Change-Id: I44a7d56cb085dc24effb24fcd34bb222b78ef4cd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176153
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
problem:
when multiple users used calc in kit in different languages,
all the users will be shows formula autocomplete in first language
list was created in, and later or new list creation was skipped.
Change-Id: I92af9b3481825e554b6aaeb4b46e7873dadc39c1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172669
Tested-by: Jenkins
Reviewed-by: Pranam Lashkari <lpranam@collabora.com>
Make it more C++ish.
The change made two functional modifications:
1. It now doesn't filter out non-string values of the localized
properties. Since commit a5649055a0
(INTEGRATION: CWS xmlfilter01 (1.38.18); FILE MERGED, 2003-04-04),
'OUString sLocaleValue' intermediate local variable was used for
values taken from XNameAccess::getByName before storing it to the
Sequence<PropertyValue>. It contradicts the documentation of the
impl_packLocalizedProperties function, created in commit
4bbc40bf5c (#84766# new mode for
locale=*, 2001-04-11), which explicitly tells that the value type
"depends from cfg entry". The commit message of the later commit
is not clear, mentioning some "repair ALLO_LOCALE mode"; but it
likely refers to the change of CONFIG_MODE_ALL_LOCALES check that
was made bitwise, instead of direct ==. I think that sLocaleValue
was used during debugging, to check the value, similar to another
debug variable - sLocaleName - also introduced in that commit; it
was simply erroneously kept in the final patch.
2. When lOutValues has an XInterface, but not XNameContainer, it
now is copied to the out sequence (it was dropped before). Likely
it won't really happen in practice, but the limitation reason was
unclear.
The use of a sequence declared out of the loop, and realloc'd in
the loop, is in fact pessimization, because such a realloc would
need to copy the existing values, only to discard them later.
Change-Id: I726c7dbeae58cbf92b53233ae4eeb3cd070375ec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172507
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
fix GPG CertificateImpl::getSHA1Thumbprint not returning a
sequence of bytes as the thumbprint. (that is what the
documented API states, and what all of the code assumed.)
now /org.openoffice.UserProfile/Data/signingkey and
encryptionkey stores the key's SHA1Thumbprint for better
identification of keys. Previously on the key name was being
used.
fix annoying NSS Certificate Database password prompt
appearing on Tools->Options if the certificate database is
password protected.
improve Tools->Options->UserData user key selection and
display of information.
add a ui test for "Sign with default certificate"
interaction in the save dialog.
Change-Id: I1036856003f58f494838e0f81ca0fe18e821f528
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171395
Tested-by: Jenkins
Reviewed-by: Sarper Akdemir <sarper.akdemir@allotropia.de>
use non-scoped interaction handler instead of the scoped
SimpleFileAccessInteraction so that errors will be handled
with correct pop-up dialogs.
Also throw the correct type of DAVException for
USC_CONNECT_FAILED in Content::Open
Change-Id: If2031dfa2796f91fad6866bc9608194c92658b96
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169519
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
This was changed in commit dd889b2903
(Resolves tdf#159573 and tdf#137931 - WhatsNew or Welcome dialog,
2024-03-27).
This change doesn't require opening a module (and checking if WhatsNew
dialog is needed) to update the configuration - it will be updated
immediately in runGraphicsRenderTests.
Change-Id: I595b6898c46998e7a0805ffbf7a710dbf0d2a5e4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168855
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Andrea Gelmini