This reverts:
commit 8556cd881270823865662e9a7700da58d11c2785
Author: Miklos Vajna <vmiklos@collabora.co.uk>
Date: Thu Mar 6 09:48:54 2014 +0100
cp#1000039 DOC import: ignore symbol charset of the symbol font
Otherwise characters unhandled by our OpenSymbol font (like Arabic 0-9
numbers) won't be rendered using an other font, as no other font
provides the symbol charset. Do this in
SwWW8ImplReader::GetFontParams(), where we already have font name ->
font family mappings for a few well-known fonts.
The DOCX filter does the same for quite some time, and that's how Arabic
numbers in text using the Symbol font were rendered, instead of little
rectangles.
The reverted commit prevented remapping symbols supported by OpenSymbol,
and it seems to have worked incidentally because of the fallback to the
“Standard Symbols L” Type 1 font which we longer support. The bug doc is
broken in master with or without this commit, but reverting this fixes
tdf#103944.
Change-Id: I17ac699fc5987e11e5c9e490895fc3c4967d3127
Reviewed-on: https://gerrit.libreoffice.org/30932
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
which are aligned to left or right against the column.
Change-Id: Ie2b6944bc0dddb0e1589842472298f787fabf596
Reviewed-on: https://gerrit.libreoffice.org/30929
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Takeshi Abe <tabe@fixedpoint.jp>
... and CharEscapementHeight if the Any is void.
This was a real error complained about in the officeotron validation
https://bugs.documentfoundation.org/attachment.cgi?id=128411https://bugs.documentfoundation.org/show_bug.cgi?id=103493
Also showed up as console warning
warn:legacy.osl:3269:1:xmloff/source/core/xmlerror.cxx:178: An error or a warning has occurred during XML import/export!
Error-Id: 0x20040003
Flags: 2 ERROR
Class: 4 API
Number: 3
Parameters:
0: CharEscapement
Exception-Message: UNKNOWN_PROPERTY
Position:
Public Identifier:
System Identifier: file:///.../103493-LotroPlan%203.8.ods
Row, Column: 2,1850164
Change-Id: Ifc634cc6b3d5d6dfa43741005ef0c9a1f7ff71fe
Text properties are applied on a shape during text insertion,
but if a placeholder shape has no text, then it has a placehodler
text which should have the right text properties.
Change-Id: I54175d52dd25915ee4d7153298e01ec07c6be1f6
Reviewed-on: https://gerrit.libreoffice.org/30881
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Rationale for changes to languagetag.hxx can be found in the bug
tdf#103855.
Change-Id: I7fa7c8a3f7b219ce08df69a3965f544ae156beab
Reviewed-on: https://gerrit.libreoffice.org/30882
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
To make the intention a bit more explicit.
Change-Id: I70ce053b9f068a2288e4a05eba55fb3e2451b561
Reviewed-on: https://gerrit.libreoffice.org/30935
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
...when doing Writer "Insert - Table of Contents and Index - Table of Contents,
Index or Bibliography...":
> sw/source/uibase/inc/cnttab.hxx:58:16: runtime error: load of value 65535, which is not a valid value for type 'TOXTypes'
> #0 0x7fbed9c2c9c8 in CurTOXType::operator==(CurTOXType const&) sw/source/uibase/inc/cnttab.hxx:58:16
> #1 0x7fbed9b711b1 in SwTOXEntryTabPage::ActivatePage(SfxItemSet const&) sw/source/ui/index/cnttab.cxx:2071:25
> #2 0x7fc217524056 in SfxTabDialog::ActivatePageHdl(TabControl*) sfx2/source/dialog/tabdlg.cxx:1126:19
> #3 0x7fc217519ac3 in SfxTabDialog::LinkStubActivatePageHdl(void*, TabControl*) sfx2/source/dialog/tabdlg.cxx:1035:1
> #4 0x7fc1f15c0e37 in Link<TabControl*, void>::Call(TabControl*) const include/tools/link.hxx:84:45
> #5 0x7fc1f157cbaa in TabControl::ActivatePage() vcl/source/control/tabctrl.cxx:1601:19
Change-Id: I458e010b10dfdf3e944c389f61595869cc41036f
Page 21 of "PAdES baseline signatures" specification from
<http://www.etsi.org/deliver/etsi_en/319100_319199/31914201/01.01.01_60/en_31914201v010101p.pdf>
says:
"The Signature Dictionary shall contain a value of ETSI.CAdES.detached
for the key SubFilter."
So in case the UI has the adescompliant checkbox enabled, write that
value instead of the Adobe default.
Change-Id: I69e606a32fb09bebd5e9b25b32150d1b8672f544
Both Writer: "Table - Insert Table... - Insert", "Table - AutoFormat Styles...";
and Calc: select multiple cells, "Format - AutoFormat Styles..." cause
> svx/source/dialog/framelinkarray.cxx:82:29: runtime error: signed integer overflow: -4702111234474983744 + -4702111234474983746 cannot be represented in type 'long'
> #0 0x7f84ef0e36ba in svx::frame::lclRecalcCoordVec(std::__debug::vector<long, std::allocator<long> >&, std::__debug::vector<long, std::allocator<long> > const&) svx/source/dialog/framelinkarray.cxx:82:29
> #1 0x7f84ef0e780e in svx::frame::ArrayImpl::GetColPosition(unsigned long) const svx/source/dialog/framelinkarray.cxx:265:9
> #2 0x7f84ef0f95ae in svx::frame::Array::GetColPosition(unsigned long) const svx/source/dialog/framelinkarray.cxx:762:20
> #3 0x7f84ef0f9e56 in svx::frame::Array::GetWidth() const svx/source/dialog/framelinkarray.cxx:787:12
> #4 0x7f852e9df8fd in ScAutoFmtPreview::CalcCellArray(bool) sc/source/ui/miscdlgs/autofmt.cxx:429:32
> #5 0x7f852e9c7740 in ScAutoFmtPreview::Init() sc/source/ui/miscdlgs/autofmt.cxx:407:5
> #6 0x7f852e9c9102 in ScAutoFmtPreview::ScAutoFmtPreview(vcl::Window*) sc/source/ui/miscdlgs/autofmt.cxx:73:5
where -4702111234474983746 = 0xbebebebebebebebe is ASan's uninitialized value
stored into ScAutoFmtPreview::mnLableColWidth et al. Those (overflowing, even)
computations on uninitialized values appear to be harmless in practice, though,
presumably because they are overwritten with "real" values soon after.
Change-Id: I487fc4681afe79c4e8532595226cba4c9c0c9b2d
instead of using the MenuBar text color, cause for Ambiance theme the
menubar is dark and its font is light, while the toolbars can be light,
so light font on light bg appears greyed out
Change-Id: I0fa4ab8eabdd3cd69eb682e5ddba8314b8c9ff0f
DataProvider class serves as an abstraction of various External
Data Importing Techniques we have and the others which
could be implemented in the future.
Change-Id: I9fc9455f7fbf9025aace4c3248df9b32f522ce52
Reviewed-on: https://gerrit.libreoffice.org/30906
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jaskaran singh <jvsg1303@gmail.com>
There are several reasons to avoid doing so:
- The mscrypto backend doesn't do that, so the previous situation was
inconsistent.
- PDF provides markup to provide a timestamp, and that's automatically
part of the signed data.
- Page 10 of "PAdES Basic" specification from
<http://www.etsi.org/deliver/etsi_ts%5C102700_102799%5C10277802%5C01.02.01_60%5Cts_10277802v010201p.pdf>
explicitly requests either not writing that data, or writing it as an
unsigned attribute (probably to underline that the value is from untrusted
source, it's the signer's computer clock).
Change-Id: I35b1a9ef4a391a24e6695353d617f27c7d96d93b
Reviewed-on: https://gerrit.libreoffice.org/30926
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
...instead of leaving it empty. (645583dfd374c8b02f3c0eeba6233a0bb5884d68 "New
compilerplugins/clang unit tests": "Checking the input files is implicitly
phony, as the compilation step doesn't generate any object files, and the link
step does nothing because there is no gb_LinkTarget_set_targettype for
CompilerTest.") In preparation for using compilerplugins/clang with clang-cl on
Windows.
Change-Id: Ica4f16a4b249537f78ce21fcbe7c4afea8214821
One from the two patches do not apply anymore. Remove both of them for
now.
Change-Id: I8e06cc28810a9dac13054282a630b0e9b716af86
Reviewed-on: https://gerrit.libreoffice.org/30924
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
Unicode variance selectors selects glyph of previous base character and
do not have character width itself.
Change-Id: Id0a0d9fcd40794b6db8ff89f84ad42a842472916
Reviewed-on: https://gerrit.libreoffice.org/29618
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: jan iversen <jani@documentfoundation.org>
CreateTextHelp() itself does the check on nullptr. No need for the
callers to do the same.
Change-Id: Ib57f3b818235a4e0fb302dda3562c9c8a29a4e54
Reviewed-on: https://gerrit.libreoffice.org/30919
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Kohei Yoshida <libreoffice@kohei.us>
So that screenshots can be generated in different languages
Change-Id: I486e48a49d6f3837058ec7ac93b5d7d3094be90e
Reviewed-on: https://gerrit.libreoffice.org/30914
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
...introduced with 789055bc2acb4c71483fd60ea258d158bd5aec10 "clang-tidy
performance-unnecessary-copy-initialization" (so partially revert it). Whatever
clang-tidy erroneously reported there, cur and next are lvalue references into
vec, so this attempted copy now actually overwrote one with the other. The
result was that if multiple JREs are detected on the system, "Options -
LibreOffice - Advanced" would list a single one multiple times.
Change-Id: I7ef454c0f37669722812383848602dc2bacf7cd1
