to deprecate it. Still possible to toggle from expert config for now,
but we should push on and remove this and all the postscript printing at
this point.
Change-Id: If8869a62616b336764720f5dc56d86b94f16ffbe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146169
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
This patch creates a separate color configuration entry for the background of the Basic Editor (svtools::BASICEDITOR). This allows the user to set the color of the Basic Editor independently from the color used as document background.
Currently the color used is DOCCOLOR, which means that if the user wants to use a different color in the Basic Editor, they must change the document color as well. However, the user may want to use f.i. a dark background in the Basic editor while maintaining a white color for documents, which is currently not possible.
By default, both color schemes "LibreOffice" and "LibreOffice Dark" use the same color for DOCCOLOR and BASICEDITOR to replicate the existing behavior. But now, if the user wants to use a different color for the Basic Editor, than it's possible to change it without affecting the color of documents.
Change-Id: I2f33b1ccb497d7e22faab7fa48cb96841785ce99
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145590
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
seen in fedora distro build. Probably since:
commit 4170b94c44
Date: Tue Nov 8 18:27:05 2022 +0100
SwModelTestBase: inherit from UnoApiXmlTest
See original discussion in https://gerrit.libreoffice.org/c/core/+/142465
use an alternative approach to solve this
[_RUN_____] testTdf143239::TestBody
Fatal exception: Signal 6
Stack:
/builddir/build/BUILD/libreoffice-7.5.0.2/instdir/program/libuno_sal.so.3(+0x48bd8)[0xffff95428bd8]
/builddir/build/BUILD/libreoffice-7.5.0.2/instdir/program/libuno_sal.so.3(+0x4fd8c)[0xffff9542fd8c]
linux-vdso.so.1(__kernel_rt_sigreturn+0x0)[0xffff955247fc]
/lib64/libc.so.6(+0x8d568)[0xffff94f2d568]
/lib64/libc.so.6(gsignal+0x20)[0xffff94ee3e80]
/lib64/libc.so.6(abort+0xf4)[0xffff94ed0284]
/builddir/build/BUILD/libreoffice-7.5.0.2/instdir/program/libvcllo.so(_ZN3psp16PrintFontManager10SubstituteERN3vcl4font17FontSelectPatternERN3rtl8OUStringE+0xbc4)[0xffff91980de4]
/builddir/build/BUILD/libreoffice-7.5.0.2/instdir/program/libvcllo.so(+0x891ea8)[0xffff91981ea8]
/builddir/build/BUILD/libreoffice-7.5.0.2/instdir/program/libvcllo.so(_ZNK3vcl4font22PhysicalFontCollection20GetGlyphFallbackFontERNS0_17FontSelectPatternEP19LogicalFontInstanceRN3rtl8OUStringEi+0xd0)[0xffff9186a7c0]
/builddir/build/BUILD/libreoffice-7.5.0.2/instdir/program/libvcllo.so(_ZNK12OutputDevice10ImplLayoutERKN3rtl8OUStringEiiRK5Pointl13KernArraySpanN4o3tl4spanIKhEE14SalLayoutFlagsPKN3vcl4text15TextLayoutCacheEPK15SalLayoutGlyphs+0x112c)[0xffff915be0c0]
/builddir/build/BUILD/libreoffice-7.5.0.2/instdir/program/libvcllo.so(_ZNK12OutputDevice12GetTextArrayERKN3rtl8OUStringEP9KernArrayiibPKN3vcl4text15TextLayoutCacheEPK15SalLayoutGlyphs+0x2c4)[0xffff915bf2b8]
/builddir/build/BUILD/libreoffice-7.5.0.2/instdir/program/libvcllo.so(_ZN18ImplFontMetricData20ImplInitTextLineSizeEPK12OutputDevice+0x74)[0xffff91873da4]
/builddir/build/BUILD/libreoffice-7.5.0.2/instdir/program/libvcllo.so(_ZNK12OutputDevice11ImplNewFontEv+0x1c8)[0xffff915b7318]
/builddir/build/BUILD/libreoffice-7.5.0.2/instdir/program/libvcllo.so(+0x4c5f70)[0xffff915b5f70]
/builddir/build/BUILD/libreoffice-7.5.0.2/instdir/program/libvcllo.so(_ZNK12OutputDevice14GetFontCharMapERN5tools5SvRefI11FontCharMapEE+0x34)[0xffff915b9004]
/builddir/build/BUILD/libreoffice-7.5.0.2/instdir/program/libvcllo.so(_ZNK12OutputDevice9HasGlyphsERKN3vcl4FontESt17basic_string_viewIDsSt11char_traitsIDsEEii+0x90)[0xffff915b9300]
/builddir/build/BUILD/libreoffice-7.5.0.2/instdir/program/libsvtlo.so(+0xff560)[0xffff8cadf560]
/builddir/build/BUILD/libreoffice-7.5.0.2/instdir/program/libsvtlo.so(_ZN11FontNameBox12CachePreviewEmP5Point+0x288)[0xffff8cae0168]
/builddir/build/BUILD/libreoffice-7.5.0.2/instdir/program/libsvtlo.so(+0x100448)[0xffff8cae0448]
/builddir/build/BUILD/libreoffice-7.5.0.2/instdir/program/libvcllo.so(_ZN9Scheduler22CallbackTaskSchedulingEv+0x30c)[0xffff917b050c]
/builddir/build/BUILD/libreoffice-7.5.0.2/instdir/program/libvcllo.so(_ZN14SvpSalInstance12CheckTimeoutEb+0x140)[0xffff919790a0]
/builddir/build/BUILD/libreoffice-7.5.0.2/instdir/program/libvcllo.so(_ZN14SvpSalInstance9ImplYieldEbb+0x98)[0xffff91979818]
/builddir/build/BUILD/libreoffice-7.5.0.2/instdir/program/libvcllo.so(_ZN14SvpSalInstance7DoYieldEbb+0xe0)[0xffff91979b70]
/builddir/build/BUILD/libreoffice-7.5.0.2/instdir/program/libvcllo.so(_ZN9Scheduler19ProcessEventsToIdleEv+0x40)[0xffff917bac84]
/builddir/build/BUILD/libreoffice-7.5.0.2/workdir/LinkTarget/CppunitTest/libtest_sw_layoutwriter.so(+0x5520c)[0xffff8d87520c]
/lib64/libcppunit-1.15.so.1(+0x1e4dc)[0xffff9549e4dc]
/builddir/build/BUILD/libreoffice-7.5.0.2/workdir/LinkTarget/Library/unoexceptionprotector.so(+0x107ec)[0xffff94e107ec]
/lib64/libcppunit-1.15.so.1(_ZN7CppUnit16DefaultProtector7protectERKNS_7FunctorERKNS_16ProtectorContextE+0x3c)[0xffff9549e1cc]
/lib64/libcppunit-1.15.so.1(_ZN7CppUnit14ProtectorChain7protectERKNS_7FunctorERKNS_16ProtectorContextE+0x320)[0xffff954969f4]
/lib64/libcppunit-1.15.so.1(_ZN7CppUnit10TestResult7protectERKNS_7FunctorEPNS_4TestERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x80)[0xffff954a06d0]
/lib64/libcppunit-1.15.so.1(_ZN7CppUnit8TestCase3runEPNS_10TestResultE+0x11c)[0xffff954a993c]
/lib64/libcppunit-1.15.so.1(_ZN7CppUnit13TestComposite15doRunChildTestsEPNS_10TestResultE+0xe0)[0xffff9549e980]
/lib64/libcppunit-1.15.so.1(_ZN7CppUnit13TestComposite3runEPNS_10TestResultE+0x58)[0xffff9549e6a8]
/lib64/libcppunit-1.15.so.1(_ZN7CppUnit13TestComposite15doRunChildTestsEPNS_10TestResultE+0xe0)[0xffff9549e980]
/lib64/libcppunit-1.15.so.1(_ZN7CppUnit13TestComposite3runEPNS_10TestResultE+0x58)[0xffff9549e6a8]
/lib64/libcppunit-1.15.so.1(_ZN7CppUnit10TestResult7runTestEPNS_4TestE+0x38)[0xffff9549f5a8]
/lib64/libcppunit-1.15.so.1(_ZN7CppUnit10TestRunner3runERNS_10TestResultERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x70)[0xffff954a6b70]
/builddir/build/BUILD/libreoffice-7.5.0.2/workdir/LinkTarget/Executable/cppunittester(+0x1443c)[0xaaaac255443c]
/builddir/build/BUILD/libreoffice-7.5.0.2/workdir/LinkTarget/Executable/cppunittester(+0x15390)[0xaaaac2555390]
/builddir/build/BUILD/libreoffice-7.5.0.2/workdir/LinkTarget/Executable/cppunittester(+0x10a38)[0xaaaac2550a38]
/lib64/libc.so.6(+0x30588)[0xffff94ed0588]
/lib64/libc.so.6(__libc_start_main+0x9c)[0xffff94ed0660]
/builddir/build/BUILD/libreoffice-7.5.0.2/workdir/LinkTarget/Executable/cppunittester(+0x10ab0)[0xaaaac2550ab0]
which: no gdb in (/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/sbin:/usr/lib/jvm/java-17-openjdk-17.0.6.0.9-0.2.ea.fc38.aarch64/bin)
You need gdb in your path to show backtraces
Error: a unit test failed, please do one of:
make CppunitTest_sw_layoutwriter CPPUNITTRACE="gdb --args"
# for interactive debugging on Linux
make CppunitTest_sw_layoutwriter VALGRIND=memcheck
# for memory checking
make CppunitTest_sw_layoutwriter DEBUGCPPUNIT=TRUE
# for exception catching
You can limit the execution to just one particular test by:
Change-Id: Ife968c5d1d49081b1d28d50a557bc90d59980fc0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145874
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Generating names more than once is unnecessary.
This may happen for defined mappings that have no explicitly
predefined language list entry.
Change-Id: I278e6d77181b661a90d0fb133cb3ca30c2a9b721
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145049
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
Only cosmetical to clarify, if possible a complete UI name is
generated, not just the language tag as before.
Change-Id: Id38e397793807762c2698948c325e6eeda989cc0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145048
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
As the container's request size of wizard pages can't be changed
directly by the UNO call setPosSize, the UNO caller can set the size
in the callback function createPage, this size will then taken as
request size. This doesn't solve the problem entirely as descriped
in tdf#152508, but the most important is, that the wizard page can
be initialized with an appropriate size at startup.
Change-Id: I1899da9c018681291559eb7c0de25a3e2e8af14e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144287
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The font sets Arabic Presentation Forms-B bit, probably because it
includes U+FEFF (Zero Width Space) which happens to be in that block but
it isn’t an Arabic code point. Filter this bit out if we already decided
it isn’t an Arabic font.
Change-Id: I9935c793b8a7592eb92db59bc75de65b81ab99fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144819
Tested-by: Jenkins
Reviewed-by: خالد حسني <khaled@aliftype.com>
(See the upcoming commit introducing that loplugin:unocast on why such
dynamic_casts from UNO types are dangerous.)
Change-Id: Ia0f628be9adf749ffdd9ad36ca9b1e8c98e29936
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144755
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(See the upcoming commit introducing that loplugin:unocast on why such
dynamic_casts from UNO types are dangerous.)
On macOS, where we implicitly use -fvisibility-inlines-hidden-static-local-var
since
<https://github.com/llvm/llvm-project/commit/d46f2c51e4c849683434bb5a0fb6164957474b8f>
"Make -fvisibility-inlines-hidden apply to static local variables in inline
functions on Darwin", the static id local var in
weld::TransportAsXWindow::getUnoTunnelId cannot be in an inline function
implicitly hidden via -fvisibility-inlines-hidden. Explicitly marking the
function as VCL_DLLPUBLIC would help, but would in turn cause MSVC error 2487
("member of a dll interface class may not be declared with dll interface"). So
just make the function non-inline in a new vcl/source/window/weldutils.cxx
(which would arguably be the best approach for the whole class, anyway).
Change-Id: Ib5615f6aae19346ea05b8b85ff77c0e5ea860994
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144331
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Both sfx2::XmlDump and css::qa::XDumper were (only) used to dump various data
from ChartModel and ChartView instances in debugging (e.g., F12 and Shift-F12 in
an SW_DEBUG=1 Writer) and testing scenarios. The problem with XmlDump was that
it was used as the target of a dynamic_cast from a UNO type, which is dangerous
(see the upcoming commit introducing loplugin:unocast for details). One fix
would have been to replace that dynamic_cast with a use of XUnoTunnel, and make
ChartModel and ChartView implement that. But those classes already implement
XDumper, so it looks more natural to use XDumper for that purpose too.
However, the information that was obtained via XDumper was rather different from
the information that was obtained via XmlDump. So make an incompatible change
to the (unpublished) XDumper, adding a kind parameter distinguishing the
original behavior of XDumper (kind == "shapes") from the original behavior of
XmlDump (kind == "").
Change-Id: Ia7379bedfc45ab62a298fdc2f030cebaf21c4885
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144145
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This patch creates a new color entry in Tools - Options - Application Colors for "Grammar mistakes". Default values are also set for the "LibreOffice" and "LibreOffice dark" schemes.
This patch also applies the selected color to the document, as well as in the SpellChecker dialog.
Change-Id: I07f79da9858b675b330540cf08cf389dce39228d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142294
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Reviewed-by: Rafael Lima <rafael.palma.lima@gmail.com>
As reported by the user, the ticks in the ruler are no longer visible. This patch draws them using the shadow color.
Tested with: gen, gtk3 and kf5
Change-Id: Ie80255544b88adfc331fac1365ce381dd90187cd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141407
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Currently SvtOptionsDrawinglayer::IsAntiAliasing() is used
in the constructor of the VCL based processor2Ds to decide
if AA is to be used or not. Using this inside the
constructors makes it currently impossible to use a
primitive renderer independent from these settings,
except when changing these settings temporarily what
may influence other renderings and is a hack.
The setting SvtOptionsDrawinglayer::IsAntiAliasing() is
intended to decide if LO shall use AA mode from user's
perspective, this means for the EditViews of the Apps
and some other occasions (previews, exports, conversions
to bitmap, ...).
This works currently since all visualizations for these
purposes use newly constructed primitive renderers. But
there is no way to use primitive renderers independent
from that setting. For future renderers which might be
used for other purposes this is not sufficient, there
has to be a method to create a renderer using e.g. AA
independent of the global setting.
To allow that, move the deciding flag to the already
used geometry::ViewInformation2D. To not change anything
initially, use the global flag for now to init that
default value at ViewInformation2D.
I took the opportunity to adapt ViewInformation2D to
no longer being read-only and not changeable, it uses
internally an impl class based on cow_wrapper already
anyways. Extending this would lead to the constructors
getting even bigger, when usually only 1-3 values
need to be changed and many usages want to copy an
existing instance and modify it. Adapted that usages
to a much smaller footprint.
Up to this point this does not change anything, but
move the usage of the SvtOptionsDrawinglayer to the
defaults (constructors) of the involved class
ViewInformation2D. Using this then in the primitive
rederers should be safe and will allow to use a
primitive renderer with or without AntiAliasing
independent of the user setting, so also for non-
EditView usages.
Also already added the PixelSnapHairline setting, this
will also be needed independent of user settings to
have full freedom of usage.
Unfortunately I cannot use SvtOptionsDrawinglayer
methods
::IsAntiAliasing() or
::IsSnapHorVerLinesToDiscrete
inside ViewInformation2D where I would need it. It's
now in drawinglayercore and thus not linked against
svtools (svt) anymore.
Thus I have to do some forwarding mechanisms to get
the correct values available in ViewInformation2D.
Not nice, caused by creating drawinglayercore...
Change-Id: I9f572ce67e5d86a242188bdc6d4ba7c9a12f6a9b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142393
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
4 bits bmp support has been dropped in March 2021 with:
a6c6f35ccc
"drop 4bpp image formats
on a path to simplifying our internal bitmap stuff, aiming to
support a smaller set of image formats, but support them
in an accelerated fashion.
"
1 bit dithered bmp support last remnant has been dropped in April 2020 with:
e3cc7b94b1
"loplugin:unusedenumconstants BmpConversion"
Change-Id: I958bea6baabb9ef21c5fa71bfc7ff96cba201245
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142375
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
no need for the indirection, which is out by one anyway, perhaps
from some time that the "none" entry was in the list vs a separate
widget as it is now
Change-Id: I028e03260f500473b42847ee748d7af8a4791ccd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142397
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
since
commit 3514ad82c4
Date: Mon Dec 10 10:02:46 2012 +0100
sw: unused SwRTFParser
Change-Id: Iaabd3d992f5e8cd8166afd3520fa8552b6219e27
we only had writer handlers back then so misplacement of these "private"
tags in unexpected context was always a hang, but with no consumers of
them we can drop them entirely and avoid the problem.
Change-Id: I6a914e5adcbebba52171d8327414f1c71ada7f19
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142288
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
In case the HTML contained markup like <![CDATA[...]]>, we simply
ignored it during import, even if e.g. the ODT import handles that
correctly.
The reason for this is that the svtools/ HTMLParser had code to parse
<!-- ... ---> style comments, but not for CDATA.
Fix the problem by introducing a new HtmlTokenId::CDATA, producing a
matching token content in HTMLParser::GetNextToken_(), and finally map
it to normal text on the Writer side.
Note that HtmlTokenId doesn't allow non-on-off tokens past ONOFF_START,
neither allows inserting a single token before ONOFF_START (it breaks
getOnToken()), so for now just add a second, dummy token to avoid
breakage.
Change-Id: I605c3c21dc11986fda5d93d36148788a638e97b4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141813
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
which doesn't preclude having a different option to force it
on/off against the system HighContrast mode setting.
Change-Id: Iab9f7f501ac5fd7bb865d07b30b6fad9f1f6809c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141386
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
New Uno command added for translation
right now it is only using deepl translation api
There's a section in the options > language settings
for setting up the api url and auth key
uno:Translate is a menu button under Format tab
which will bring up Language Selection dialog for translation.
DeepL can accept html as the input for translation, this new
feature leverages that by exporting paragraphs/selections to
html and paste them back without losing the formatting (in theory)
This works good in general but we may lose formatting in very complex
styled sentences.
Translation works in two ways;
1) Whole document
when there is no selection, it assumes that we want to translate whole
document. Each paragraphs is sent one by one so that the output timeout
can be minimum for each paragraph.
2) Selection
Change-Id: Ia2d3ab2f6757faf565b939e1d670a7dedac33390
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140624
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Updating the preview of the embedded PDF object in the bugdoc leads to
Acrobat generating a new preview, we throw away the old one, write the
new one to the document, and next time the document is opened, we can't
parse it, so the preview is lost for the user.
The reason for this seems to be that sometimes Acrobat generates a
broken WMF: the first 4 bytes is 0x0002 (DISKMETAFILE from the
MetafileType enum), but the next 4 bytes is 0x6f43, which means that the
header size is 56966 bytes long, but the whole preview is 29291, so this
WMF looks broken.
Fix the problem by adding error handling before we insert the WMF we get
from Acrobat as a graphic stream to the document storage: don't update
the graphic stream if the data is something that can't be handled by
VCL's graphic filters. svt::EmbeddedObjectRef::GetReplacement() has a
similar error handling, which is why the preview only gets broken on
document reload.
No testcase, this only happens on Windows and only in case a problematic
handler for PDF is installed, which is hard to test from 'make check'.
Change-Id: I9e1ce979e58a155fa5e72e31cd9ea38258bb8b6a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141229
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
And use an overloaded helper function with a better (?) unified name
to show that the result is not an O(U)String.
Change-Id: I8956338b05d02bf46a6185828130ea8ef145d46b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141203
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
In Calc, when you drag a tab to move it, the arrows pointing to where the tab will be positioned are always in black, even in dark mode.
This patch fixes this issue.
Change-Id: I9079099c5ac1a8fb767eaa105cf8863e54d0ec3f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140760
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
With a LanguageTag::ScriptType a language tag appears in the
corresponding Western/Asian/Complex language list.
Change-Id: Ifa7fe784ebee33990b552e8df0f5555dc98667f0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140974
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
Caolán McNamara