Age | Commit message (Collapse) | Author | Files | Lines |
|
... and functions returning array/matrix.
Same as for TRANSPOSE() and FREQUENCY() but not mentioned in
ECMA-376-1:2016 OOXML.
Change-Id: I1e9f1151b2bc0b7de892f4f3d9f91b9a6b86b67f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104249
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
For example the DSL syntax will be:
>> Choose Tab number 2 in 'tab_id' from parent_id
We don't need DSL change as it will already handled by normal Tab grammar
Change-Id: I51f294134be88c4ac88baf73c53d81187a023061
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101516
Tested-by: Jenkins
Reviewed-by: Ahmed ElShreif <aelshreif7@gmail.com>
|
|
Bug happens in the "top" branch of SplitContentNode().
SwTextNode::CutImpl() sends several hints to the SwTextFrame so that it
invalidates itself; a SwInsText and a SwDelText most prominently.
The SwInsText won't have an effect because the target node doesn't have
text frames yet, but the SwDelText should be sufficient to update the
text frames' MergedPara and invalidate the text frames.
The MergedPara is re-created by SwTextFrame::RegisterToNode() anyway,
but that *doesn't* invalidate the SwTextFrame.
Then an additional SwDelText is sent, which will *not* invalidate the
SwTextFrame, because its MergedPara is up-to-date so nothing gets
deleted by the hint.
It's unclear why the LockModify() is done here, since CVS initial
import, perhaps it's some premature optimization; try to remove the
manual sending of SwDelText and just let CutImpl() do it.
Also remove an odd assert in UpdateMergedParaForMove() that i don't
understand the reason for now.
Change-Id: Iba7196556f614356dba4def74f039a88f392eb0f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104219
Tested-by: Michael Stahl <michael.stahl@cib.de>
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
Change-Id: I8315f585b899031d238d339d3833c9f0d536dfab
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104236
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Ic4d5b50051cee4ab65a366ed7d26c222a7ca3008
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104227
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Otherwise, from-scratch `make CppunitTest_sw_uiwriter` failed for me on Linux
with
> warn:vcl.builder:1934376:1934376:vcl/source/window/builder.cxx:467: DBG_UNHANDLED_EXCEPTION in VclBuilder
> when: Unable to read .ui file exception: com.sun.star.container.NoSuchElementException message: file:///~/lo/core/instdir/share/config/soffice.cfg/svt/ui/editcontrol.ui ~/lo/core/xmlreader/source/xmlreader.cxx:66
and
> warn:vcl.builder:1939531:1939531:vcl/source/window/builder.cxx:467: DBG_UNHANDLED_EXCEPTION in VclBuilder
> when: Unable to read .ui file exception: com.sun.star.container.NoSuchElementException message: file:///~/lo/core/instdir/share/config/soffice.cfg/svx/ui/sidebarstylespanel.ui ~/lo/core/xmlreader/source/xmlreader.cxx:66
and
> warn:vcl.builder:1943074:1943074:vcl/source/window/builder.cxx:467: DBG_UNHANDLED_EXCEPTION in VclBuilder
> when: Unable to read .ui file exception: com.sun.star.container.NoSuchElementException message: file:///~/lo/core/instdir/share/config/soffice.cfg/sfx/ui/infobar.ui ~/lo/core/xmlreader/source/xmlreader.cxx:66
Change-Id: I8f1ece408b8c5f0e389378f15a2652a45cb93103
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104235
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Bisection of tdf#137367 points to the commit fixing bnc#887230
Make sure we don't regress here
Change-Id: I54877ca5fae8c7074baf1211ec983c1bc1961f59
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104232
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
of (simplified export) of not filled custom shapes by
adding missing fill="none" to a:path.
Note: in OpenDocument, unfilled shape path is defined
by draw:enhanced-path command "F", see section 19.145
in ODF v1.2.
Co-authored-by: Szabolcs Tóth
Change-Id: I0be2aada3deb06828216e0441c91c389a673f87c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104205
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Exclusion by experimental on/off updated
Change-Id: I714b8ffc5a148d09607ab20763b6d35de2a9e2be
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104231
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
|
|
Change-Id: I6d9afb87b8d99e3c622b9d69fbfa88528adadb81
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104228
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Embedded charts of DOCX documents were lost or replaced
by images during conversion to native ODT format,
resulted by bad handling of XEmbedPersist objects in
EmbeddedObjectContainer.
Note: Add missing loext:external-data to ODF 1.3 schema
definition to fix ODF validation error in gerrit.
See commit 2054af83fefb955e20de2b40178a11726525057e
(fdo#72520 : Added property to store external data path in chart)
and commit a49a9dab3168c03a539adc131f2ade03236edb69
(fix one more ODF validation error).
Change-Id: I9edff9af3a79370ea447ffc6078da3520d0c6f63
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104104
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: I68c20dfbedb84660cf25df785e1e0b13a7592994
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104229
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If93fa126f10393a250cc1ad64bee28e84c42a6b5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104226
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I53e10fbebfd07c471ddd9b264562317251700500
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104225
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
so we can support dynamically disable/enable dnd
Change-Id: Icfec79c332ef073e04be5a57747e849b27098732
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104221
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
The problem is that the destructor of the vector maFocusableObjects
ends up dispose()-ing every element, which calls back into
AccessibleFocusManager to remove the element from the vector, which
invokes its destructor a 2nd time.
Move it to the stack so it doesn't double-free itself.
ERROR: AddressSanitizer: heap-use-after-free on address 0x612001571c00 at pc 0x7fc5e723ca72 bp 0x7fffbaa8d6d0 sp 0x7fffbaa8d6c8
READ of size 1 at 0x612001571c00 thread T0
#0 0x7fc5e723ca71 in cppu::WeakComponentImplHelperBase::release() cppuhelper/source/implbase.cxx:84:9
#1 0x7fc595211b27 in cppu::PartialWeakComponentImplHelper<com::sun::star::accessibility::XAccessible, com::sun::star::accessibility::XAccessibleContext, com::sun::star::accessibility::XAccessibleComponent, com::sun::star::accessibility::XAccessibleEventBroadcaster, com::sun::star::awt::XWindowListener>::release() include/cppuhelper/compbase.hxx:86:36
#2 0x7fc5952093e4 in rtl::Reference<sdext::presenter::PresenterAccessible::AccessibleObject>::~Reference() include/rtl/ref.hxx:113:22
#3 0x7fc59522acd4 in void std::_Destroy<rtl::Reference<sdext::presenter::PresenterAccessible::AccessibleObject> >(rtl::Reference<sdext::presenter::PresenterAccessible::AccessibleObject>*) /usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/bits/stl_construct.h:140:19
0x612001571c00 is located 64 bytes inside of 312-byte region [0x612001571bc0,0x612001571cf8)
freed by thread T0 here:
#0 0x4be997 in free (instdir/program/soffice.bin+0x4be997)
#1 0x7fc5ea2a5104 in rtl_freeMemory sal/rtl/alloc_global.cxx:51:5
#2 0x7fc5952097f4 in cppu::WeakComponentImplHelperBase::operator delete(void*) include/cppuhelper/compbase_ex.hxx:66:11
#3 0x7fc595211e07 in sdext::presenter::PresenterAccessible::AccessibleObject::~AccessibleObject() sdext/source/presenter/PresenterAccessibility.cxx:67:28
#4 0x7fc5e74a11b4 in cppu::OWeakObject::release() cppuhelper/source/weak.cxx:233:9
#5 0x7fc5e723cb05 in cppu::WeakComponentImplHelperBase::release() cppuhelper/source/implbase.cxx:86:18
#6 0x7fc595211b27 in cppu::PartialWeakComponentImplHelper<com::sun::star::accessibility::XAccessible, com::sun::star::accessibility::XAccessibleContext, com::sun::star::accessibility::XAccessibleComponent, com::sun::star::accessibility::XAccessibleEventBroadcaster, com::sun::star::awt::XWindowListener>::release() include/cppuhelper/compbase.hxx:86:36
#7 0x7fc5e7194115 in com::sun::star::uno::Reference<com::sun::star::uno::XInterface>::~Reference() include/com/sun/star/uno/Reference.hxx:110:22
#8 0x7fc5e71f3944 in com::sun::star::lang::EventObject::~EventObject() workdir/UnoApiHeadersTarget/udkapi/comprehensive/com/sun/star/lang/EventObject.hdl:18:27
#9 0x7fc5e723d395 in cppu::WeakComponentImplHelperBase::dispose() cppuhelper/source/implbase.cxx:118:5
#10 0x7fc595211e27 in cppu::PartialWeakComponentImplHelper<com::sun::star::accessibility::XAccessible, com::sun::star::accessibility::XAccessibleContext, com::sun::star::accessibility::XAccessibleComponent, com::sun::star::accessibility::XAccessibleEventBroadcaster, com::sun::star::awt::XWindowListener>::dispose() include/cppuhelper/compbase.hxx:90:36
#11 0x7fc5e723c6e9 in cppu::WeakComponentImplHelperBase::release() cppuhelper/source/implbase.cxx:79:13
#12 0x7fc595211b27 in cppu::PartialWeakComponentImplHelper<com::sun::star::accessibility::XAccessible, com::sun::star::accessibility::XAccessibleContext, com::sun::star::accessibility::XAccessibleComponent, com::sun::star::accessibility::XAccessibleEventBroadcaster, com::sun::star::awt::XWindowListener>::release() include/cppuhelper/compbase.hxx:86:36
#13 0x7fc5952093e4 in rtl::Reference<sdext::presenter::PresenterAccessible::AccessibleObject>::~Reference() include/rtl/ref.hxx:113:22
#14 0x7fc59522acd4 in void std::_Destroy<rtl::Reference<sdext::presenter::PresenterAccessible::AccessibleObject> >(rtl::Reference<sdext::presenter::PresenterAccessible::AccessibleObject>*) /usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/bits/stl_construct.h:140:19
Change-Id: I95151807e9182ed5f43b63792fba86f83ee0bad8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104208
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
Change-Id: If1194bd3364fef8b2d0c26c22854745d0fb7b412
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104223
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id41fba75133e3473dcb834c72ff2ecfb317ecb79
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103603
Tested-by: Andras Timar <andras.timar@collabora.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104201
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
Change-Id: I487b5dc148f5a3d0d45f198c00179002841242ce
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104213
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This is a case when a left margin appears as direct formatting on a
paragraph, the paragraph has a style and the style has the same left
margin. But the paragraph has a numbering as well: so it's not valid to
deduplicate the left margin from the direct formatting, because then the
left margin from the numbering will be used, which can be a different
value.
Change-Id: I5e27502b8d505bdfddfdc910858f62e501db35a5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104220
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I030368a09905f236ce43fa5d08740641d694fbad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104199
Tested-by: Jenkins
Reviewed-by: Rizal Muttaqin <riz_17_oke@yahoo.co.id>
|
|
wrong since...
commit acb1c390539730957fb509f18f469fc7f6133082
Date: Thu Oct 1 15:44:32 2020 +0200
Resolves tdf#137187 - More dictionaries via extensions dialog
Change-Id: I01010d07d356dd696fd3432971b20194008c9487
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104218
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
REQUEST_START is triggered with --show.
Change-Id: I83fec4f0ae4df15ed7974f484b3001e886f82a65
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104217
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
no logic change
Change-Id: I1172e97feb5e78b68ed395231a698459687493aa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104216
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I3ac7848170e8075fe192731495361cb2c5777e75
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104215
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
UNO command and linkbutton interaction replaced with the internal dialog
DICT_REPO_URL removed, README adjusted
Change-Id: I401737b538da229ac0d432007e7564105672ff40
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103769
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
|
|
Information rearranged, empty icons instead of hidden,
background and scaling of thumbnail
Change-Id: Iae095134a717cb50670bf5d1786774c6424d283e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104079
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
|
|
Only OpenGL and Skia implement the BlendBitmap*() calls, and so I
disabled the direct path in an attempt to avoid forcing the mirroring
if it takes place. But there's also the DrawAlphaBitmap() call
that is implemented for other backends. So always do the mirroring
already there if it takes place.
Change-Id: I8c4c96ea18ac55ebad041e0d28c4228542d9b2e6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104206
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I6a2096151bbe7b2bdf9210b3d023926270a9987a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104211
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I4a3dd3d30fcab84bf9987f71a9c9cf0657ecfbb6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104210
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I9884c1cd579fff85c425ffe51e1ed60f7095ad90
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104209
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
I don't see the point of taking the detour via GDIMetaFile and
then immediately drawing using it to a bitmap. Simply draw directly
to a bitmap. Especially given that when drawing to a metafile
some fast cases are skipped, e.g. DrawTransformedBitmapEx()
avoids DrawTransformBitmapExDirect() and resorts to using the slow
BitmapEx::getTransformed(). E.g. with tdf#136223. this makes
SfxPickListImpl::AddDocumentToPickList() go from 30% to 13%
of the total document loading time.
Change-Id: Ib1643eddfc2b75a3d7be60138fb5226352805826
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104114
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: Ic54ac8377bbfbd2c5b5b995ef8615bf0961bd100
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104051
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Tested-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
|
|
BGR(A) is actually the format used by most VCL backends (Cairo and
Skia at least).
Change-Id: I1574aadabafcea274049d4c7021352913813bae2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104130
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
SolarMutex added
Change-Id: I18c6683e7a26892ce7f1d019cb1ee59ce03981ac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104198
Reviewed-by: Muhammet Kara <muhammet.kara@collabora.com>
Tested-by: Jenkins
|
|
With some documents SvpSalGraphics::drawTransformedBitmap()
ends up calling StretchAndConvert() with 8bit grayscale source
bitmap (e.g. OutputDevice::DrawTransformBitmapExDirect() uses them
as dummy alpha masks). But ImplFastBitmapConversion() doesn't
handle this case, so StretchAndConvert() falls back to doing it
manually, easily making this 3x slower. But 8bit grayscale
bitmaps sort of are actually non-paletted, so this is easy
to optimize.
Change-Id: I93aa3f283c8a182d76f3aa267ebd471e63d945e8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104129
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Apparently this code path has never been tested.
Change-Id: I112543ad4f403bb50e5789ceacf57e0c009a9ef7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104128
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
JPEG reads RGB, but e.g. with Skia the default bitmap format is BGRA.
Change-Id: Iad1a9e99f286b03db0fa683c14d70b8ad48d3d9d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104120
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
changed font order priority.
1. put 'Noto Sans KR' ahead of 'Noto Sans CJK KR'.
Because, New Noto Sans CJK font change the name.
New Noto Sans CJK V2.001 released on 10 Apr 2019.
In these font files, removed 'CJK' on names.
Nowadays, New Linux distributions includes Noto CJK font V2.0.
In Korean Linux environments, Noto CJK font v2.0 'Noto Sans KR' & 'Noto Serif KR' are already set default.
2. fixed Windows fonts for Korean on LibreOffice
I watched Windows 10's Korean Font List
Microsoft Docs: Font List Windows 10 - Typography; Korean Supplemental Fonts
https://docs.microsoft.com/en-us/typography/fonts/windows_10_font_list#korean-supplemental-fonts
I missed 굴림체;GulimChe, 돋움체;DotumChe, 굴림체;GulimChe.
So. I added MS Default Korean fonts.
As a result, I changed font order and add default Windows font names.
Ref.
1: Google Noto CJK fonts Repository: https://github.com/googlefonts/noto-cjk
2: Microsoft Docs: Font List Windows's Korean supplemental fonts
https://docs.microsoft.com/en-us/typography/fonts/windows_10_font_list#korean-supplemental-fonts
cf.Apple Docs - Format Chinese, Japanese, or Korean text in Pages on Mac
https://support.apple.com/guide/pages/format-chinese-japanese-or-korean-text-tanfbd4156e/mac
Change-Id: I12594aa8f3122c05810a07a718aae7ec185ba481
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104189
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
... SwXLinkNameAccessWrapper and TableHeadingCheck
See tdf#94879 for motivation.
Change-Id: I1108abc0d4ee6179c0b4d4dbe18af0730edbd2ba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104200
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
unsigned integer overflow: 0 - 1 cannot be represented in type size_t
Change-Id: Iba74ce28752e4024e0921f91f28866fd9eaf248e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104195
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: If95bf624e4bd18368f41b350fc3675e2675576c3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104190
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: If39302042d3e53798aaa8564fddc8ddd6e539712
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104179
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
ignore properties in SEPX which aren't section properties
Change-Id: I191acbd8d602d0c59ce541cecb847d7d57c1bc3a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104178
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Distinguishing both Korean and Japanese fonts from all CJK[Chinese-Japanese-Korean] fonts such as Noto CJK font series and Source Han Sans series, etc.
For the first time, I added Hardcode script for "Noto" CJK fonts.
The "Noto" CJK fonts support to Simplified Chinese, Traditional Chinese, Traditional Chinese HK, Japanese, and Korean (Pan-CJK fonts).
Nowadays, Noto CJK Fonts are shown '简繁'.
Noto font's KR(Korean, 한국어/한글) & JP(Japanese,日本語) represent Korean(KR, It shows '한글') and Japanese(JP, It shows '日本語'), respectively. These are not expressed in Chinese fonts, such as Simplified Chinese(简) and Traditional Chinese(繁).
Also, Both TC(Traditional Chinese) and HK(Hong Kong) represent 繁. It don't shown 简繁.
so, SC(Simplified Chinese) represent 简, It don't shown 简繁
So, I fixed Font select option's Noto CJK-series font Examples on LibreOffice
Noto Sans CJK HK 简繁 -> Noto Sans CJK HK 繁
Noto Sans CJK JP 简繁 -> Noto Sans CJK JP 日本語
Noto Sans CJK KR 简繁 -> Noto Sans CJK KR 한글
Noto Sans CJK SC 简繁 -> Noto Sans CJK SC 简
Noto Sans CJK TC 简繁 -> Noto Sans CJK TC 繁
Noto Sans Mono CJK HK 简繁 -> Noto Sans Mono CJK HK 繁
Noto Sans Mono CJK JP 简繁 -> Noto Sans Mono CJK JP 日本語
Noto Sans Mono CJK KR 简繁 -> Noto Sans Mono CJK KR 한글
Noto Sans Mono CJK SC 简繁 -> Noto Sans Mono CJK SC 简
Noto Sans Mono CJK TC 简繁 -> Noto Sans Mono CJK TC 繁
Noto Serif CJK JP 简繁 -> Noto Serif CJK JP 日本語
Noto Serif CJK KR 简繁 -> Noto Serif CJK KR 한글
Noto Serif CJK SC 简繁 -> Noto Serif CJK SC 简
Noto Serif CJK TC 简繁 -> Noto Serif CJK TC 繁
However, It is only support to Noto CJK fonts and lack of distinguish fonts for all CJK[Chinese-Japanese-Korean) fonts.
So, I think that change the code and improving the ability to distinguish fonts between Korean, Chinese and Japanese.
1. `remove Hardcode script for "Noto" CJK fonts
2. add hardcode script at attemptToDisambiguateHan(UScriptCode eScript, OutputDevice const &rDevice) and change distinguish among Korean, Japanese and Chinese fonts.
Former
- static const sal_Unicode aKorean[] = { 0x3131 };
- static const sal_Unicode aJapanese[] = { 0x3007, 0x9F9D };
- static const sal_Unicode aTraditionalChinese[] = { 0x570B };
- static const sal_Unicode aSimplifiedChinese[] = { 0x56FD };
Korean: U+3131 ㄱ Hangul Letter Kiyeok
Japanese: U+3007 〇 Ideographic Number Zero & U+9F9D 龝
Traditional Chinese: U+570B
Simplified Chinese: U+56FD
That code’s problem
Both Japaese kanji U+3007 〇 and U+9F9D 龝 also uses in Korean & Chinese.
U+3007 〇
Definition: zero
It uses in CJK(Chinese, Japanese and Korean)
It usually uses number expression in MS Excel, LibreOffice.
U+9F9D 龝
Definition: autumn, fall; year
Mandarin Chinese reads qiū
Korean Hanja sound is 추 chu
Japanese Kun sound is ‘AKI' or ‘TOKI’
Japanese On sound is ‘SHUU’
That meaning likes ‘秋’.
Korean
[한자 너 어디 있었니?] 54. 분탕 焚蕩 http://www.incheonilbo.com/news/articleView.html?idxno=1019040
참고로 가을날 벼에 달라붙은 메뚜기 모양을 한 글자인 龝(추)는 秋의 고자(古字)로 서예가들이 멋을 부리기 위해 사용하기도 한다.
Japanese
「龝」の漢字‐読み方・意味・部首・画数 - 漢字辞典 https://kanjitisiki.com/jis2/2-3/020.html
漢字の「龝」についてです。「秋」の異体字です。
Chinese
龝 - 中國哲學書電子化計劃 https://ctext.org/dictionary.pl?if=gb&char=%E9%BE%9D
《康熙字典·四》: 秋:〔古文〕龝《唐韻》七由切《集韻》《韻會》雌由切《正韻》此由切,音鰌。
Also, Both U+570B 國 and U+56FD 国 doesn't distinguish CJK languages.
Because, 'U+570B 國’ uses in Traditional Chinese, Korean, Japanese texts.
U+570B 國
Korean: 國
21國 정상급 26명 온다…평창서 `외교 올림픽` https://www.mk.co.kr/news/politics/view/2018/01/66693/
핵융합발전 프로젝트 韓國이 주도..."ITER 부품의 70~80% 도맡아" http://www.dt.co.kr/contents.html?article_no=2020072802109931731004
Japanese: 國
ORANGE RANGE、母校の吹奏楽部・琉球國祭り太鼓とのライブを公開 https://news.yahoo.co.jp/articles/c6a7e9bb83e46662a8638cd5373a5c71d144cb8b
Traditional Chinese: 國
國家森林遊樂區免費入園一次 上路一週最熱門是這地方 https://news.ltn.com.tw/news/life/breakingnews/3237355
Also, 'U+56FD 国’ uses in both Simplified Chinese and Japanese.
U+56FD 国
Japanese: 国
日本人の子ども連れ去りは国ぐるみの誘拐? 批准した国際条約、国内で適用せずは許されるのか https://www.47news.jp/news/5057377.html
Simplified Chinese: 国
中国国际云书馆上线运行 http://world.people.com.cn/n1/2020/0726/c1002-31797808.html
My suggestion to change code
Changed
+ static const sal_Unicode aKorean[] = { 0x4E6D, 0x4E76, 0x596C };
+ static const sal_Unicode aJapanese[] = { 0x5968, 0x67A0, 0x9D8F };
+ static const sal_Unicode aTraditionalChinese[] = { 0x555F, 0x96DE };
+ static const sal_Unicode aSimplifiedChinese[] = { 0x4E61, 0x542F, 0x5956 };
CJK language uses Ideographs(Chinese characters) in common.
But, For Ideographs(Chinese characters) in the same sense, the shape and code points of Chinese characters are different for each country. Also. Some languages make Ideographs such as Korean-made Ideographs and Japanese-made Ideographs.
I added Korean-made Ideographs & Japanese-made Ideographs & only use characters in Japanese.
1.Korean-made Ideographs: U+4E6D 乭 (It reads ‘돌 dol’ in Korean. It only uses in Korean) & U+4E76 乶 (It reads '볼 bol' in Korean. It only uses in Korean)
2.Japanese-made Ideographs: U+67A0 枠 (It reads ‘waku’ in Japanese. It only uses in Japanese)
3. only use in Korean & Japanese.
U+596C 奬
It usually uses in Korean.
U+5968 奨 & U+9D8F 鶏
These usually use in Japanese.
The Traditional Chinese(繁體中文) form of prize, reward is U+734E 獎
The Simplified Chinese(简体中文) form of prize, reward is U+5956 奖
The Korean Hanja(한국 한자/韓國 漢字) form of prize, reward is U+596C 奬
The Japanese Kanji(日本 漢字) form of prize, reward is U+5968 奨
For example, Chinese characters(Ideographs) for Rooster
The Traditional Chinese(繁體中文) form of the rooster is both 雞 (U+96DE) [It says jī ] & 鷄 (U+9DC4)
The Simplified Chinese(简体中文) form of the rooster is 鸡 (U+9E21) [It says jī ]
The Korean Hanja(한국 한자/韓國 漢字) form of the rooster is 鷄 (U+9DC4). [It says 계, revised romanization of korean is "Gyeo”]
The Japanese Kanji(日本 漢字) form of the rooster is 鶏(U+9D8F). (It says とり[tori] , にわとり[niwatori])
Adobe CJK Type Blog - Year of the rooster
https://blogs.adobe.com/CCJKType/2017/01/year-of-the-rooster.html
4. only use in Traditional Chinese
U+555F 啟 & U+96DE 雞
The Traditional Chinese(繁體中文) form of open & begin is U+555F 啟
The Simplified Chinese(简体中文) form of open & begin is U+542F 启
The Korean Hanja(한국 한자/韓國 漢字) form & The Japanese Kanji(日本 漢字) form of open & begin is U+5553 啓
For example, Chinese characters(Ideographs) for Rooster
The Traditional Chinese(繁體中文) form of the rooster is both 雞 (U+96DE) [It says jī ] & 鷄 (U+9DC4)
The Simplified Chinese(简体中文) form of the rooster is 鸡 (U+9E21) [It says jī ]
The Korean Hanja(한국 한자/韓國 漢字) form of the rooster is 鷄 (U+9DC4). [It says 계, revised romanization of korean is "Gyeo”]
The Japanese Kanji(日本 漢字) form of the rooster is 鶏(U+9D8F). (It says とり[tori] , にわとり[niwatori])
5. only use in Simplified Chinese
U+4E61 乡 & U+542F 启 & U+5956 奖
The Traditional Chinese(繁體中文) form of country;rural;village is U+9109 鄉
The Simplified Chinese(简体中文) form of country;rural;village is U+4E61 乡
The Korean Hanja(한국 한자/韓國 漢字) form of country;rural;village is U+9115 鄕
& The Japanese Kanji(日本 漢字) form of country;rural;village is U+90F7 郷
The Traditional Chinese(繁體中文) form of open & begin is U+555F 啟
The Simplified Chinese(简体中文) form of open & begin is U+542F 启
The Korean Hanja(한국 한자/韓國 漢字) form & The Japanese Kanji(日本 漢字) form of open & begin is U+5553 啓
The Traditional Chinese(繁體中文) form of prize, reward is U+734E 獎
The Simplified Chinese(简体中文) form of prize, reward is U+5956 奖
The Korean Hanja(한국 한자/韓國 漢字) form of prize, reward is U+596C 奬
The Japanese Kanji(日本 漢字) form of prize, reward is U+5968 奨
So, I checked and built it.
I found that distinguish among Korean, Chinese, and Japanese fonts from all CJK[Chinese-Japanese-Korean] fonts such as Noto CJK font series and Source Han Sans series, etc.
Change-Id: Icc1f3ea31227f77c0e3ad0ec3ed03663deedee51
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99951
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
This is a fix for regression introduced by
61a35560cb412d7ab0e3d0574eec4a790e3b9dfd
Sidebar wasn't properly refreshed in Online eg.
in Impress change 'Background' in sidebar 'Slide' deck
to 'Color' -> resulted in overlapping content
Change-Id: Id64f5d8694908d28cf5fa9787b65e555fb317e35
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103724
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104012
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
On core side, if user clicks on a tab with right mouse button, clicked tab is selected.
So, for core side, if this feature will be desired, some more modification will be needed.
Change-Id: Ic4755b27b8ba98d3a6aa086b2e0a3566d095ba16
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103685
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104078
Tested-by: Jenkins
|
|
isn't available there.
While here, change the #ifdef check from __FreeBSD_kernel_ to __FreeBSD__, because pthreads API is userspace (read, belongs to libc).
Change-Id: I83e76b5502a6dfa1be5d3598eb1367f25815396e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104098
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
Change-Id: Id6496b020dbdec9005eb4326a2397dcc1dee70bb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104193
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I3ed7c8954d929fe3ba53379df3428433a1d7f287
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104192
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|