The "final" was removed in commit
e06f2bb00137655dbf6f0a8c8c2fc555720f4d3f (tdf#142467 crash on calling
'getInfoHelper' in final class, 2021-05-26)
and commit
6cb1745c24 (tdf#142467: Update comments
with GCC bug ID, 2021-05-31)
due to a bug in gcc <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100797>.
Now it has been amost 3 years past and that gcc bug has long been fixed,
so it is time to restore the "final".
Change-Id: I7db9fe59209cfbae4c04bb3a91cd764db9a38d98
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163447
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
...when hidden by autofilter.
The "show hidden filter elements as inactive" feature was added and improved by:
commit 2d1df9f3dc
(tdf#117276 sc: Show hidden filter elements as inactive elements)
commit 2085e90fe8
(FilteredRow is not a property of the column, tdf#117276 follow-up)
commit 7321db3cad
(Related tdf#117276 sc: Show hidden filter elements as inactive elements)
commit 1953394837
(Name FilteredRow what it is, not hidden; tdf#117276 follow-up)
Those changes correctly made normal hidden filter elements as inactive,
but failed to do so for Empty and Error entries.
This patch shows the hidden Empty and Error entries as inactive and unselected.
Also, do not show the Empty entry at the top of the list in case it is inactive.
Change-Id: Ibcd758cebc0692b04b162cdfc3e06eceb86b17da
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162166
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Kevin Suo <suokunlong@126.com>
Tested-by: Kevin Suo <suokunlong@126.com>
The previous order makes the UI tooltip does not match with the
numbering style shown, per tdf#148023.
Also add a commonly used Chinese-specific outline numbering style.
The other old styles with the Chapters and Sections etc are removed
because they are useless.
Change-Id: I585cd0e704af35125c7c38561f500e83f1a465dd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160081
Tested-by: Jenkins
Reviewed-by: Kevin Suo <suokunlong@126.com>
The previous order makes the UI tooltip does not match with the
numbering style shown, per tdf#148023.
Also re-arrange the remaining Chinese-specific styles to make the most
commonly used ones come first.
Change-Id: I913180b1ca385e8a604b16b63ebfa130aca059c4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160080
Tested-by: Jenkins
Reviewed-by: Kevin Suo <suokunlong@126.com>
This adds the [1],[2],[3] style of numbering to the Simplified
Chinese locale data. This will show up when one clicks the
numbering toolbar icon.
Change-Id: I8b54746b431384e682f4161a3e99211b4147bad1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160059
Tested-by: Jenkins
Reviewed-by: Kevin Suo <suokunlong@126.com>
... DrawElement twice in WriterXmlEmitter"
This reverts commit 9ea9d3ccc0.
The reason for the revert:
It causes regressions as indicated in tdf#157589 and tdf#153969.
That commit may be my misunderstanding of the code.
Change-Id: Idd188bf83721d309623a7f8484d064327a3a23af
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159811
Tested-by: Jenkins
Reviewed-by: Kevin Suo <suokunlong@126.com>
... and remove unsed include.
XComponentContext.hpp is used in pdfiprocessor.hxx but not in drawtreevisiting.hxx.
XMultiServiceFactory.hpp is not used drawtreevisiting.hxx.
Change-Id: Ic98cbcdcacd07cf2163e02ac569781f70edd953c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143570
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Follow up to:
commit 3a2f0e4772
Author: Kevin Suo
Date: Sun Nov 20 00:10:14 2022 +0800
Resolves tdf#152083: Ligatures are incorrectly reversed in Draw pdf import
The unit test is adjusted accordingly to reflect this change.
Change-Id: I051a76ed38f76ff92197e1dc87cbfa7151b8ac35
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143606
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This is used to check whether a TextElement is rtl. We will need this
in WriterXmlOptimizer::optimizeTextElements() as well, in a separate commit.
Change-Id: Iee2ff5990450421153bb7c5afe9526c555f2d0ba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143598
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This was a typo which causes the asian font in pdf (e.g. Chinese)
always shown as the system default font on pdfimport.
Change-Id: Ic118f8585fb40dfc4bc5bc12651da95bc7961ae4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143607
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
The method PDFIProcessor::mirrorString() was removed, and
::comphelper::string::reverseString was used, by Kevin Suo in commit
69e9925ded.
The old PDFIProcessor::mirrorString() did two things:
1) Reverse the code points in the string. However, due to its use of iterateCodePoints(&i)
rather than iterateCodePoints(&i, -1) (i.e. iterating in forward rather than reversed order),
the reverse was not functioning at all.
2) Use GetMirroredChar (i.e. the icu unicode u_charMirror() which was dropped in
commit 720a093461) to get the mirrored-image of
characters with the Bidi_Mirrored properties.
Stephan Bergmann restored the #1 in commit 50d73574b6
(by introducing comphelper::string::reverseCodePoints). However, the #2 was not restored.
I do not see a clear reason to drop #2 (at least this is an area I don't quite familiar
with), so it's better to restore it as well, in *this* commit, named as SubstituteBidiMirrored.
Change-Id: Ic263097938310e6e04f3b95bb12e4f4e834198f2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143041
Tested-by: Jenkins
Reviewed-by: Kevin Suo <suokunlong@126.com>
...and remove the TODO comments.
Also, comment out the test for string ٱلسََّل which is related to tdf#152083 and will be fixed in a separate commit.
Change-Id: I075145be1ff58c16e976c710fbf8f55fc6752af1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142962
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
... back to grid type "lines and characters".
Also enable "Snap to characters" for grid type "lines and characters" and disbale it
for grid types "lines only" and "no grid".
Change-Id: I101c8d80a79798fc6c992da766c658c3ba8802dd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142513
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
GetActiveView() may return a nullptr when previously we are in Calc
window and then click the controls on the writer dialog.
Change-Id: Ia4dcd58b19c40a3e6cd0a791b7645d5fd2dcb9f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142508
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Ruby height is used to show the ruby line in square page mode only (e.g. to show the
Pinyin etc above or below base line). When not in square page mode (i.e., when in
normal mode), the ruby height should be zero.
The code was trying to set the ruby height to zero by using the following:
m_xRubySizeMF->set_value(0, FieldUnit::TWIP);
and then pass this to aGridItem.SetRubyHeight in SwTextGridPage::PutGridItem.
However, there seems to be always a conversion loss, thus each line will have a tiny
ruby height, which makes the vertical space not enough to hold the desired number
of lines on the page.
Fix this by setting ruby height to zero directly in SwTextGridPage::PutGridItem if
we are not in square page mode.
Change-Id: I24a74b96c12eb58e46e163e2a9c73b540023ab39
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142243
Tested-by: Jenkins
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
This was done for Draw in sdext/source/pdfimport/tree/drawtreevisiting.cxx,
but was not done for Writer. Without this, continuous spaces in PDF will
show only one space on pdfimport using the Writer pdfimport filter.
Change-Id: I2279d9b1750e07f5743aeba80a3fd553bc037d13
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141527
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Discovered when working on commit f6004e1c45.
To reproduce, you can print the content of aOutput2 above the line:
https://opengrok.libreoffice.org/xref/core/sdext/source/pdfimport/test/tests.cxx?r=f6004e1c#836,
and then you get the xml content as shown in:
https://bugs.documentfoundation.org/attachment.cgi?id=183217,
in which you can see that there are duplicated draw:frame(s) with identical draw:z-index.
To dig into the problem, you may take a look at the following code block:
1 for( const auto& rxChild : elem.Children )
2 {
3 PageElement* pPage = dynamic_cast<PageElement*>(rxChild.get());
4 if( pPage )
5 {
6 for( auto child_it = pPage->Children.begin(); child_it != pPage->Children.end(); ++child_it )
7 {
8 if( dynamic_cast<DrawElement*>(child_it->get()) != nullptr )
9 (*child_it)->visitedBy( *this, child_it );
10 }
11 }
12 }
13
14 for( auto it = elem.Children.begin(); it != elem.Children.end(); ++it )
15 {
16 if( dynamic_cast<DrawElement*>(it->get()) != nullptr )
17 (*it)->visitedBy( *this, it );
18 }
In the for loop in lines 1:12:
* "elem" is a "DocumentElement" which is derived from "Element". It's childen are PageElement(s).
* "pPage" is a "PageElement" which is also derived from "Element". It's childen are DrawElement(s).
* "child_it", as in the for loop in lines 6:10, is a "DrawElement" which is derived from
"GraphicalElement", whereas "GraphicalElement" is derived from "Element".
In this block, the code goes through each of the pages and visit the DrawElements there.
The code in lines 14:18 seems to assume that, a DrawElement, in addition to be a child of
PageElement, may also be a child of DocumentElement. See the comment in souce code.
Yes, it may be. For such DrawElement(s), the visiting is done in lines 14:18 separately.
Note that The above code uses dynamic_cast to determine whether a node is a DrawElement or not.
The problem is that, in determining whether the node during the 2nd visiting is a DrawElement,
it accidently used "== nullptr". This may be an inadvertent error. If the dynamic_cast is a nullprt,
then it is not a DrawElement and the visiting should not be done there.
Resolve this by using "!= nullptr" in the second dynamic_cast checking.
Change-Id: I066100e98039d505d8b10c390954e014b78cff4f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141680
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This patch adds a new template category named "Localization", to be used for
templates created by our l10n team for each locale, so that languages which
requires special layout or formatting (such as CJK or CTL) can have their own
templates bundled by default.
This patch aslo adds a (general purpose) Writer template for the Simplified
Chinese language. Chinese language, by convention, need to format the
document to have the first line of the paragraph be indented by 2 characters.
The font size, line spacing, paragraph margin etc also need special treatment.
If the Chinese users start writing using the current default Writer template,
they need to adjust the style formatting every time to meet their needs.
Although this template can be provided as an "extension" on the extension
website, in practice very few people will go to the extension website and
look for such templates.
Such bundled templates can also be added by other l10n teams. The
extras/README.md will be updated in a separate patch to include documentation
on how to add such templates and have their template names translatable on
weblate.
This does not completely resolve the issue in tdf#86483, which requests to
"Implement different default templates per locale". However, with this patch,
we are a step closer to set a choosen template when the user switch to a
certain UI.
Change-Id: Ic295482354f343e981eb20908907bd6a945b7120
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140802
Tested-by: Jenkins
Reviewed-by: Laurent Balland <laurent.balland@mailo.fr>
This is a followup to commit a97bae545d.
Previously different areas within the "filter" module used their own "*ResId" code
to get the translated string. They did the same thing without any difference in
purpose and implementation.
Unify this to use FilterResId instead.
Change-Id: Idccf74601a89b5786e1f61a04631436147710bb9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141692
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This unit test was disabled for Windows build in commit fc45e54be6,
due to the "crashes on the windows jenkins boxes".
In this patch, I:
1. Rename the test name to show its purpose for easier reading;
2. Test the whole string all at once using xpath, rather than use indexOf().
This way we can not only test the existance of the characters, but also
the order they appear.
3. Activate it for Windows build and hope it passes on Jenkins.
4. Remove the std::cout debug code, and use CPPUNIT_ASSERT_EQUAL_MESSAGE
instead, so that the xml content (i.e. aOutput) is only shown when the
assertion fails.
5. Move the test document to testdocs directory.
Change-Id: I39084eb4ddc451ecac5183213b7e6166facf617b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141601
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This is a followup to commit 69e9925ded
for the fix of tdf#104597.
The Writer pdf import filter code is similar than the Draw part.
However, many fixes to the Draw part was not done in the Writer part historically.
This patch ports the fix of text run in the Draw part to the Writer
part. There is a todo related to continuous spaces issue which should
be fixed separately.
Also use CPPUNIT_ASSERT_EQUAL_MESSAGE for the output of xml content
instread of using std::cout, in case of unit test failure.
Change-Id: Id013700524750e6e5283d85eeab72d8075f16f1b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141420
Tested-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
For the simple Arabic string: ٱلسَّلَامُ عَلَيْك, the xpdfimport binary generates the
follwing (drawchar) sequences:
كَ
يْ
لَ
عَ
مُ
ا
لَ
سَّ
ل
ٱ
(i.e., in reversed order, one character by one character).
Before this patch, after pdfimport the text shows up as لَسَّلٱ كَيْلَعَ مُا, which is reversed.
It was surposed to combine these characters into text frames in
DrawXmlOptimizer::optimizeTextElements(Element& rParent) (sdext/source/pdfimport/\
tree/drawtreevisiting.cxx:677), but actually it was not combined successfully there.
The single characters were then passed to sdext/source/pdfimport/tree/drawtreevisiting\
.cxx:105, one by one, in the hope that the strings could be mirrored. The mirroring
failed, because one single character, even after mirroring, always equals itself.
The DrawXmlOptimizer::optimizeTextElements failed to combine the characters into
one text frame, because the condition:
(rCurGC.Transformation == rNextGC.Transformation || notTransformed(rNextGC))
would never be true, as at least its horizontal position is different. A further analysis
indicates that we do not need to check the transformation here at all, as this is an
optimizer for a TextElement and in case a character is transformed then it would already
be in a different draw element (thus will never be combined with this TextElement).
After the fix of DrawXmlOptimizer::optimizeTextElements which now successfully
combines the characters, there is another issue in the old PDFIProcessor::mirrorString
function. It seems to mirror the characters within a word, but if a string contains
two words, then the two words are not successfully switched (e.g. for string "abc def"
it produces "cba fed" rather than "fed cba"), which is not suitable for
the case of RTL which requires all the characters been reversed. Fix this by using
comphelper::string::reverseString.
Change-Id: Ifa210836f1d6666dd56205ff0d243adfb4114794
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141231
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Currently there are 32 localized template name strings defined in:
include/sfx2/strings.hrc. However, in sfx2/source/doc/doctempl.cxx
only 30 were used. This makes STR_TEMPLATE_NAME31 ("Simple") and
STR_TEMPLATE_NAME32 ("BPMN"), although already localized, not show up
on the Template Manager UI.
This patch adds these two strings in the sfx2/source/doc/doctempl.cxx,
so that they properly show as localized strings on the UI.
Change-Id: I64bb28cfe0a4d3b4b41c9114de7223014f6a3cfe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140785
Tested-by: Jenkins
Reviewed-by: Rafael Lima <rafael.palma.lima@gmail.com>
Reviewed-by: Laurent Balland <laurent.balland@mailo.fr>
...to Source Han Sans CN Normal and Source Han Serif CN Medium for Simplified Chinese UI, so that
the font shown is not bold.
Tranditional Chinese and Japanese settings are not touched. It is up to the
zh-TW and JA l10n team to decide whether to apply the same change.
This does not resolve the bug itself, but makes the UI usable when the
system has Source Han Sans CN or Source Han Serif CN fonts installed,
so that the default font used is normal weight rather than bold.
Change-Id: I52753448d886854d92ba8a26d8b03bf42522735f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128798
Tested-by: Jenkins
Reviewed-by: Franklin Weng <franklin@goodhorse.idv.tw>
Reviewed-by: Eike Rathke <erack@redhat.com>
For Chinese, format code NATNUM7 and NATNUM8 are "short lower
case text" and "short upper case text", respectively, see [1].
We need full lower and full upper here for numbering purpose, not
"short" form. E.g. for number 100, we need "一百" (lower case)
and "壹佰" (upper case), rather than "百" which is in short form.
Use NATNUM12 for chinese lower, and NATNUM5 for Chinese upper.
See bug 147054 for the reason why we do not use NATNUM4 for Chinese lower.
[1] https://help.libreoffice.org/latest/en-US/text/shared/01/05020301.html
Change-Id: I69c93d62f1026117a6d403ade63a9abfbe5c73f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129143
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
SAL_WARN should be some message which showns where the program
runs abnormally. Normal debugging output code should be SAL_INFO,
and if you have set it to SAL_WARN for easy debugging you should
set it back to SAL_INFO or delete those lines when submit.
Otherwise our dbgutil terminal will be flood with unrelated
messages
Change-Id: I0767bfbeb7a21f208be12208009ccda8b6c72bab
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118763
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Previously we only supported CIRCLED NUMBER ONE through CIRCLED NUMBER TWENTY.
Unicode aready has CIRCLED NUMBER TWENTY ONE through CIRCLED NUMBER FIFTY.
This improves Circled Numbering, especially for CJK.
E.g. ➀, ➁, ➂, ... ㉑, ㉒, ㉓, ... ㊽, ㊾, ㊿.
Change-Id: I7c4c851f03522fef9d44163da7450cf69aab3889
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129015
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
Previously, if you set the first line indent to auto, then if you change
the line height, the first line indent will also change. I do not see a
reason to change the first line indent value in case of change in line
spacing, even for English language.
Some languages (e.g. Chinese) may have set the auto first line indent
to be 2 characters of the current font, but if the first line indent
changes when line height changes, then this 2-character rule is not possible.
For compatibility with old documents, a compatability flag
'AutoFirstLineIndentDisregardLineSpace' is added in this patch, thus this
patch only has effect to new ODF documents. DOC/DOCX documents will also
benefit from this patch, no matter old or new, because, as Miklos Vajna
has pointed out, Word does not have the auto first line height feature.
Change-Id: I1e2ddc33cce4ff9b3b2b4122445894f724d5bcd1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125627
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
* Update helpcontent2 from branch 'master'
to 4251a294d02ab5ae1c136b7bd90ba5c69bf8cce5
- Fix the error message for sc error code 524 "Error: Not a valid reference"
The error message on the UI is:
NC_("STR_LONG_ERR_NO_REF", "Error: Not a valid reference")
rather than "invalid references".
Change-Id: I86c1bb0d950fd30654c82d80011164eec25da43b
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/127514
Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
rather than Error: Wrong data type.
STR_LONG_ERR_NO_VALUE was marked as "Error: Wrong data type" in
the source code. It was translated in the en_US UI as "Error:
No result", which seems to be intentionally. This causes confusion
for other languages.
This error code is used for case FormulaError::NoValue and this
FormulaError enum entry is used in various places, most of them
indicates that it is used because of no value is returned.
"Wrong data type" should be a reason why there was "no value"
returned, thus "Wrong data type" should be a subset of "No value",
but anyway STR_LONG_ERR_NO_VALUE != "Wrong data type".
Change-Id: Ie0e355ba02e9800fca2263744ed74ada700bfbeb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127512
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
Per Wechat discussion by our Simplified Chinese l10n team.
上方 and 下方 are written languages which are more suitable for
cross-reference context, while 上面 and 下面 are spoken languages.
Also in this way they are consistent with MS Word.
Change-Id: Iccf8c330b2e5a04be3916b810a29ea0d62f26225
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125533
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
Replace it with the defined SC_STYLE_PROG_STANDARD macro.
Hard-coded style names can cause problems such as tdf#134161.
Change-Id: I27b5dfd3a4f60785622d51fe903484982f51f803
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124644
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
The default cell styles (when creating a new Calc document), as returned by orcus
parsing, are built-in English names, as defined in sc/res/xml/styles.xml. These
names can be localized. On non-English UI, all these (localized) styles names
will be forced to use the localized "Default" as their parent because there is
no such non-localized parents in the localized style tree on UI.
In this patch, I added SC_DLLPUBLIC to ScStyleNameConversion::ProgrammaticToDisplayName,
then used this function to convert the parent style name to the (localized) UI name.
Change-Id: I3689211a10c60a5e7b2b273b6c15a4da92f0d633
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124556
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Eike Rathke <erack@redhat.com>
so that they can be reused in other parts of the code base.
Need to change them to inline to avoid "defined but not used" compiling error.
Change-Id: I44de7c2ebbc9ae57c229f89faf69a788013d7816
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124643
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
when parsing the default Calc styles.
As an initial matter, orcus currently does not support XML_font_size_asian,
XML_font_size_complex, XML_font_weight_asian, XML_font_weight_complex etc in:
https://gitlab.com/orcus/orcus/-/blob/master/src/liborcus/odf_styles_context.cpp#L128
While this need to be improved by Orcus, actually in Calc we provide
the default font attributes in sc/res/xml/styles.xml and it makes no
sense to set different font size/weight/posture for each language type.
As a result we apply the same font attributes of latin to all these
languages.
Change-Id: I1b105fecce45aa22c6b72e15305e25dc6669d2cb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124536
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...ScHTMLStyles can handle those MSO-Number-Formats again.
The CSSHandler was added by the following commit, after which the
sc htmlimport can parse the CSS stylesheets and set number formats
of table cells accordingly:
commit 24d8e4eaf4
Author: Kohei Yoshida
Date: Thu Jul 28 00:46:55 2011 -0400
Parse CSS in the <style> content and set number formats to cells.
However, this was broken since "selector_name" does not no
longer functions in the handler since upgrade to orcus 0.9:
commit edb38d702d
Author: David Tardon
Date: Thu Jun 4 16:09:48 2015 +0200
update to liborcus 0.9.1
And further the selector_name was then removed by the
following commitd due to loplugin:unreffun checks:
commit c76a8580c6
Author: Miklos Vajna
Date: Fri Jun 5 12:29:36 2015 +0200
sc: loplugin:unreffun
commit 9eeac5506b
Author: Miklos Vajna
Date: Fri Jun 5 12:32:10 2015 +0200
sc: another loplugin:unreffun
And then this was further broken by the following commit, in which
it removed the mrStyles of type "ScHTMLStyles" from the CSSHandler
class:
commit 5d86154f49
Author: Noel Grandin
Date: Tue Sep 18 09:57:26 2018 +0200
loplugin:unusedfields improve search for unused collection fields
This patch partially reverted those code, revised the
CSSHandler member functions to make it work. More handler
functions need to be implemented.
Note that this bug is still not resoved yet because the orcus
css parser does not accept css strings to include unquoted
non-ascii chars as property values. This will be addressed in
a separate patch.
Change-Id: I8883f5a9362d9476dbfa9a2eed283c6f5c18305d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123715
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Previously the unittest testTdf143959_nameFromFontFile did not
fail even if the fixing code in wrapper.cxx is removed.
That was because the "if (xHolder.is())" condition is always false
in the unittest run, which suggests that the calling of
com.sun.star.awt.FontIdentificator through the uno did not work
in some circumstances. See comments in:
https://gerrit.libreoffice.org/c/core/+/120815
In this patch, we call the vcl::Font::identifyFont directly rather
than through the uno calling. This is proven to work in both the
manual and unittest running.
Change-Id: I6334bca2defaa27cf6ac72af3d621fbb59e57980
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123358
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...e.g. Thin, Extra-Light, Light, Semi-Bold, Bold, Extra-Bold and Black.
Previously the xpdfimport code passes the isBold value which is bool value.
sdext.pdfimport accepted this value from the xpdfimport output and check
whether a font is bold or not. However, there are many other FontWeight
features more than a "bold".
This patch changes the isBold to the GfxFont::Weight type, and changed the
sdext.pdfimport isBold bool type (in FontAttributes) to an OUString fontWeight.
The value for the fontWeight is set according to the GfxFont::Weight passed
by xpdfimport, and then this fontWeight is passed to the ODF xml generation
stage and used there directly.
Now the Semibold and Light (as shown in the unittest file) can be currectly
handled. However, for other weights the parseFontFamilyName still need to
be updated, but before doing that I plan to refector this function as the
current logic is very difficult for maintennance.
Change-Id: If2ce5f0f41c83843d8a6aeb30134b3faf99ba877
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123339
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
In OOXML, 1 indent = 3 space char width.
-----
The Old Method:
-----
XLSX Import:
As per the line:
sal_Int32 nIndent = getUnitConverter().scaleToMm100( 3.0 * maModel.mnIndent, Unit::Space );
assume the width of space char is 88, then:
If the OOXML indent is 1, then nIndent would be 264.5, and casted to 264.
If the OOXML indent is 2, then nIndent would be 528.5, and casted to 528.
If the OOXML indent is 3, then nIndent would be 792.5, and casted to 792.
...
Also, as Mike Kaganski has pointed out, we use twips in sc indent internally, thus it is wrong to convert to Mm100 unit here.
XLSX Export:
As per the line:
nTmpIndent = (nTmpIndent + 100) / 200;
Assume we did not edit the document upon open, and simply save it. Now:
If our indent is 264, then the calculated OOXML indent would be 1.82, and then casted to 1, while the expected value is 1.
If our indent is 528, then the calculated OOXML indent would be 3.14, and then casted to 3, while the expected value is 2.
If our indent is 792, then the calculated OOXML indent would be 4.46, and then casted to 4, while the expected value is 3.
...
Then if you reopen the saved xlsx file with Calc, the increament of indent continues on each save which causes serious
format loss.
Most importantly, if you change the indent of cells using the Calc toolbar indent icon, one-click would be 10pt = 200 twips,
see defined macro SC_INDENT_STEP. This causes a mess when you change the indent in an xlsx document.
-----
The New Method
-----
In this patch, I have changed the XLSX import to convert the excel indent unit to 3-spaces-width *in twips*.
Then, per code advice from Mike Kaganski, as a mirror operation, I have changed the XLSX export logic to detect the width
of the space char (which *should* be the same as the one detected at the time of xlsx import), and use this width to convert
the indent in twips unit to excel unit. This way, the indent will remain the same on xlsx export.
-----
TODO:
-----
1. On xlsx import of the file tdf130104_indent.xlsx, the default font (i.e. font for the "Normal" style) is "Times New Roman".
However, when the UI locale is set to Simplified Chinese and "Asian" option is enabled in Tools->Options->Language Settigns->
Languages->"Default Languages for Documents", upon resave as xlsx, the default font for the document is changed to "Noto Sans CJK SC"
on my system, which causes the space-width detected to be different from the width detected on xlsx import. This seems to be another
bug, see tdf#131349. (Luckily the unit test in this patch passes, this is because the change of space width resulted from the change
in default font is very small thus the conversion is not impacted.)
2. The UI part need to be improved, so that after xlsx import, if the user hit the "Increase Indent" or "Decrease Indent" toolar
icon to change the indent, Calc should be able to detect that we are operating in an xlsx file, thus the "increment" should
be 3 * width of space char, rather than the current SC_INDENT_STEP. Also, the if the user changes the default font of the xlsx
document, the Calc should recalculate the indent for each cell to reflect the possible change in width of space char.
Change-Id: I5f7a4ecbcd93079d1c19db3b0b641dda949f6fbf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123111
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Per OpenDocument specs:
* The <text:s> element only has a "text:c" attribute.
* The <text:tab> element only has a text:tab-ref attribute.
seen in the SAL_WARN message:
warn:xmloff:221658:221658:xmloff/source/text/txtparai.cxx:137: unknown attribute urn:oasis:names:tc:opendocument:xmlns:text:1.0 text:style-name value=text13
...
Change-Id: I02a29ac2c9f9db026caec19238cd97111ce587c9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118946
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Case 1: As discussed in the bug report, SimSun does not have a
"bold" font. In PDF it uses fill+stroke rendering mode (i.e.,
Text Render Mode is 2), see CoreTextStyle::CoreTextStyle, as a
faux bold (fake bold) feature. For faux bold, the text render
fill color is the same as the stroke color.
Case 2: Also, it is noted that if you apply real "outline"
characters in Writer and export to PDF, on Draw PDF import
the text render mode is also 2, but the text render fill color
is different than the stroke color.
However, I would argue that for this case on PDF export Writer
should set the render mode as 1, not 2, per PDF specs, which is
another issue to be improved.
The old code treated all these two cases as "outline".
This patch:
1) treats render mode 2 as faux bold if the stroke color is the
same as the fill color; and
2) still treat it as outline if the fill color and stroke color
are different.
This way, the real outline remains as outline characters while
the faux bold (fake bold) becomes bold again on pdf import.
This patch Also fixed some incorrect use of <style:text-properties>
attributes per OpenDocument specification.
This patch depends on change-ID I50a510ab9e5483f859ea2a767ea977ea3f065a2e
which guesses the bold/italic if the font indentifaction had failed
for whatever reason.
Change-Id: Idabb22ea9b01ba53733c3acbd9de843790ebe8ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118156
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Simplify the code and hopefully improves performance.
The previous code used a long for loop within which it used many duplicated parseFontRemoveSuffix. That for loop was simply intended to remove the font family name suffixes. However, the rResult.familyName is a OUString and this type already has the function of removing suffixes which is more efficient.
Also, defined a list of suffixes to be removed in the header file. New suffixes can be easily added to this list.
Change-Id: Idfa11cfe60e2e34a1f7456d29562a89eb3de7662
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118734
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...determining the bold/italic/underline etc.
The purpose for reading a font file is that in case the font attributes determined by the xpdfimport process is not enough, then we use the lo core font classes which read in the font file and then determine whether it is bold, italic etc.
However, while this works in some cases, it does not work in many cases when the font file was actually a subset and a toUnicode map is followed in the PDF, see tdf#78427.
In addition, in case the information collected from the xpdfimport process is enough, there is no need to read the font file.
This commit removes the read of font file part. Also, this commit uses gfxFont->getNameWithoutSubsetTag() to get the font name with the subset tags removed, thus simplified the code in wrapper.cxx while also improves performace as the remove of subset tags is only run when the font is a subset (the previous code did this for all the font names).
Change-Id: I94c1ad8e743abfab81cf0a46da178d4d8b212427
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118733
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Newer version of git has a --progress option to show the progress when running "git submodule update". This is useful in our ./g command expecially when we are building the code with l10n languages enabled and the network connection is slow. Without this I do not see where I am for the update process and may think it have died.
Change-Id: I4c9e1e9bccbd8e6ca2ea2b44f5b6d6d90cad1506
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117922
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
* Update helpcontent2 from branch 'master'
to e36e33937f9cda7fde9ab56f9eb25f6f549700c7
- tdf#142531: fix help css for Simplified Chinese display on Linux
The font "system-ui" may cause trouble in some system, although it may look good in several systems.
See e.g. https://infinnie.github.io/blog/2017/systemui.html.
This change removes the "system-ui" font from the list, still put "Segoe UI" before any others, but moves "sans-serif" forward so that it falls back to the UI font in most linux distros.
Tested on Win10 and this does not impact the display for English or Chinese, but really improves a lot on Linux (Fedora 32 for me).
Change-Id: I1cba731cb846d1dc8c708b12510167c48de539e5
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/116487
Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
* Update helpcontent2 from branch 'master'
to 226a545d33667a0c9526593a5182ac0a849933e2
- tdf#142417: Improve convertfilters.py and add API Names column
This commit involves two parts:
1. Improved the convertfilters.py helper script to make sure
the generated convertfilters.xhp file is complete, accurate
and containing no duplicated entries, and also add codes
to also generate API Names column, as discussed in tdf#142417.
Importantly, the code is modified to generate fixed IDs,
rather than the previously random IDs or sequential IDs which
may make the PO translation strings to show fuzzy when the
file is re-generated.
2. This helper script is run and the convertfilters.xhp is
updated.
3. The default css is modified to better display the page.
There is no need to set overflow=auto for the DisplayArea,
otherwise the scrollbar goes to the bottom of that area which
is not visible. Also added a css class to display smaller
fonts for the table.
Change-Id: I8a5c73c9d6a0c0b44fc7db6cb67b140bfeb8b4be
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/116405
Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
This commit:
1. Updated the license header;
2. Added docstrings and notes to help the users to understand the API and code.
3. Make the code to create a new sheet named "data", define named ranges in it,
modify the named range, define another named range, fill values in the cells
related to the named ranges, the calcualte sum of each named range, and also
calculate the difference between the two named ranges. The results are stored
in the sheet named "information".
4. Cell alignment and background color methods are also used in this example.
5. Only show the parent function in the UI.
Change-Id: Iba6111dc3754f054deeb0baf902dbff1eb3bfa2c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108530
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
The previous one, when run from within the application, gives a
runtime exception.
This commit rewrites this example to:
1. Hide the private function from the UI;
2. Create a new blank Calc file instead of operating directly in the existing file;
3. Set cell colors to draw a "LO" picture in the sheet.
4. Added docstrings and API reference links.
Change-Id: I120a3ede0629a5657fec18f1b0909dfc4bc7ad1c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104720
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...which makes the OK/Cancel buttons invisible under small displays.
This commit changed the height of these widgets. Also I did some tweats to the UI file
and the width so that the edit dialog of these fields looks nicer (at least on my display).
Change-Id: I9f39727afd566d75db525c5a5cafe2eabb66d7ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107965
Tested-by: Jenkins
Tested-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
As per discussion in the bug report, in some systems these fonts are named as
"Noto {Sans, Serif} {SC,TC,HK,KR,JP}", instead of ""Noto {Sans, Serif} CJK
{SC,TC,HK,KR,JP}".
It is noted that the KR section has already been updated.
Also removed the non-mono fonts from zh_CN section.
Change-Id: I0e67b895649502780b8e5cdff2b7d6dade3ff6b7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104222
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
* Modified the code to be more pythonic.
* If "len(theString) == 0", then "not theString" evaluates to True.
* "theString[0].isupper()" and "theString[1].isupper()" can be combined.
* Remove unused imported string module
* Wrap long lines
* run autopep8 to prettify
* ...
Change-Id: Ic8aaa0728a43936cd4c6e1ed590e01ba8f0fbf5b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104136
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Kevin Suo