This may reduce some degree of dependency on boost.
Done by running a script like:
git grep -l '#include *.boost/scoped_array.hpp.' \
| xargs sed -i -e 's@#include *.boost/scoped_array.hpp.@#include <memory>@'
git grep -l '\(boost::\)\?scoped_array<\([^<>]*\)>' \
| xargs sed -i -e 's/\(boost::\)\?scoped_array<\([^<>]*\)>/std::unique_ptr<\2[]>/'
... and then killing duplicate or unnecessary includes,
while changing manually
m_xOutlineStylesCandidates in xmloff/source/text/txtimp.cxx,
extensions/source/ole/unoconversionutilities.hxx, and
extensions/source/ole/oleobjw.cxx.
Change-Id: I3955ed3ad99b94499a7bd0e6e3a09078771f9bfd
Reviewed-on: https://gerrit.libreoffice.org/16289
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
When a SwTxtFormatInfo is created to format a paragraph, pre-compute the
result of vcl::ScriptRun::next() and cache it for future calls to
OutputDevice::GetTextBreak() and GetTextWidth().
This requires adapting a bunch of methods to pass the additional
parameter, and some classes to backup and restore the cache when they
replace the text of the SwTxtFormatInfo.
There is some code in vcl OutputDevice::ImplPrepareLayoutArgs()
to modify the passed string and replace digits depending on
"meTextLanguage" member; try to set it to the correct value when
creating the layout cache (unfortunately it's not possible if the user
sets the CTL Numerals config to the non-default "Context" value).
Another issue is the check in OutputDevice::ImplLayout() if there is
a mpConversion member on the font; apparently this is used to translate
between different Symbol fonts, so not very important; just ignore the
cache in this case.
This reduces vcl::ScriptRun::next() from 11 to 0.36 billion callgrind
cycles when built with GCC 4.9.2 -m32 -Os (which is still 16% of the
formatting).
Change-Id: I61fb8530333f2e7a9199f767c00cf2181ba49951
Reviewed-on: https://gerrit.libreoffice.org/14732
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
When a SwTxtFormatInfo is created to format a paragraph, pre-compute the
result of vcl::ScriptRun::next() and cache it for future calls to
OutputDevice::GetTextBreak() and GetTextWidth().
This requires adapting a bunch of methods to pass the additional
parameter, and some classes to backup and restore the cache when they
replace the text of the SwTxtFormatInfo.
There is some code in vcl OutputDevice::ImplPrepareLayoutArgs()
to modify the passed string and replace digits depending on
"meTextLanguage" member; try to set it to the correct value when
creating the layout cache (unfortunately it's not possible if the user
sets the CTL Numerals config to the non-default "Context" value).
Another issue is the check in OutputDevice::ImplLayout() if there is
a mpConversion member on the font; apparently this is used to translate
between different Symbol fonts, so not very important; just ignore the
cache in this case.
This reduces vcl::ScriptRun::next() from 11 to 0.36 billion callgrind
cycles when built with GCC 4.9.2 -m32 -Os (which is still 16% of the
formatting).
Change-Id: I61fb8530333f2e7a9199f767c00cf2181ba49951
Reviewed-on: https://gerrit.libreoffice.org/14732
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
I believe the intent was to "retarget unresolved pLogCluster[n] to a glyph inside the cluster".
Unfortunately in the loop that detects clusters there was a typo and we are only indexing
element 0 of the array:
// retarget unresolved pLogCluster[n] to a glyph inside the cluster
// TODO: better do it while the deleted-glyph markers are still there
for( n = 0; n < nCharCount; ++n )
if( (p = pLogCluster[0]) >= 0 )
break;
That just doesn't make any sense, I believe we should be accessing pLogCluster[n].
If not, then why not just do:
p = pLogCluster[0];
n = nCharCount - 1;
Change-Id: I9d8873541b5c794071d69c0f63df88f17a352904
Reviewed-on: https://gerrit.libreoffice.org/13876
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
Basically, the issue noted here (justification adjustment issues in CTL) is
a legacy problem caused by emulating the EmrText structure, which is an
Enhanced Metafile (EMF) structure (or "object"). The EmrText structure holds
an array of inter-character spacing widths for text. It is used in the EMF
records EMR_EXTTEXTOUTA and EMR_EXTTEXTOUTW, which is flawed in that it
doesn't consider issues around CTL scripts and only cares about character
interspacing - i.e. it maps to each printable character, and doesn't take into
consideration other sorts of glyphs.
Change-Id: Ib7ae994758a835e9d8cb5f479a0b91d3d5809b8c
Stumbled across such redundant visibility re-specifications when looking at the
odd case of cppu_unsatisfied_iquery_msg declared CPPU_DLLPUBLIC in
cppu/source/cppu/cppu_opt.cxx and used in inline code in
include/com/sun/star/uno/Reference.hxx with only a declaration lacking
CPPU_DLLPUBLIC visible, and wondering how that actually works on Windows.
However, this plugin is probably not worth it being run all the time, so
committing it to compilerplugins/clang/store/.
Change-Id: Ibc3c4e7499213de1b419ce7eb85455cb832e1510
most of length in vcl are calculated in 'long'
but array of X position tend to be in sal_Int32.
As a prep work to be able to support 'double'
as the base type of Device Coordinate, harmonize
the use of 'long' for non-float coordinate.
Change-Id: I7cb33301ff6a5e2c62247b36a4e07e168a58a323
Using the central definition adds consistency and cleans up many ad hoc
declarations. The type sal_GlyphId will become a class in the future so
that its bitfield operations etc. can then be isolated into nice methods.
(cherry picked from commit c0a84ad10964fb7a65b6239cbe1cef8698b5d17b)
Conflicts:
vcl/aqua/source/gdi/salatslayout.cxx
vcl/aqua/source/gdi/salgdi.cxx
vcl/generic/glyphs/gcach_ftyp.cxx
vcl/generic/print/genpspgraphics.cxx
vcl/generic/print/glyphset.cxx
vcl/generic/print/glyphset.hxx
vcl/headless/svptext.cxx
vcl/inc/generic/genpspgraphics.h
vcl/inc/generic/glyphcache.hxx
vcl/inc/os2/salgdi.h
vcl/inc/quartz/salgdi.h
vcl/inc/salgdi.hxx
vcl/inc/sallayout.hxx
vcl/inc/unx/salgdi.h
vcl/inc/vcl/fontmanager.hxx
vcl/inc/win/salgdi.h
vcl/os2/source/gdi/os2layout.cxx
vcl/os2/source/gdi/salgdi3.cxx
vcl/source/gdi/pdfwriter_impl.cxx
vcl/source/gdi/sallayout.cxx
vcl/source/glyphs/gcach_ftyp.hxx
vcl/source/glyphs/gcach_layout.cxx
vcl/source/glyphs/glyphcache.cxx
vcl/source/glyphs/graphite_layout.cxx
vcl/unx/generic/fontmanager/fontmanager.cxx
vcl/unx/generic/gdi/gcach_xpeer.cxx
vcl/unx/generic/gdi/gcach_xpeer.hxx
vcl/unx/generic/gdi/salgdi3.cxx
vcl/unx/generic/gdi/xrender_peer.hxx
vcl/unx/headless/svpgdi.hxx
vcl/unx/headless/svppspgraphics.cxx
vcl/unx/headless/svppspgraphics.hxx
vcl/win/source/gdi/salgdi3.cxx
vcl/win/source/gdi/winlayout.cxx
Change-Id: Ic629131950360e2df4c15db30d6a5362193c6330
It seems that some Indic fonts assign 'mark' glyph class to combining
spacing marks (spacing not non spacing) so my reliance on the glyph
class to set the IS_DIACRITIC flags broke those fonts. This is a bandaid
to get around the issue, plus some long rant! (at this rate, I'll be
writing "The VCL haters handbook" pretty soon).
Change-Id: I3ff892acf746d50182573f94e7e8c3c6f9464ae0
... found at http://msdn.microsoft.com/library/cc233965.aspx (the 5th or
6th place I'm aware of where MS defines LCIDs, all different ...)
* a bunch of new definitions up to Windows 8.1
* lots of cross-checks done with SIL, Ethnologue, ...
Change-Id: Ifae8e676558c6712fe752856acca600d05d0a63f
using a heuristic that assumes a glyph with unknown char mapping
is the continuation of the preceding glyph. If there is no known
preceding mapping use the run bounds.
(cherry picked from commit 576e4ea626e1c1ffcf9d025e692db62fed8c3cab)
Change-Id: I70e58a02d814e14e9592ff8efc0ae630346ae5df
This is only used in conjunction with SalLayout::GetNextGlyphs() in
vcl/source/gdi/pdfwriter_impl.cxx to retrieve the fallback font, if any,
used to layout the given glyph, but it is a very convoluted way to do a
straight forward thing, and hard to adapt for new SalLayout
implementations.
So now I just pass a fallback fonts array, when requested, in
GetNextGlyphs() itself.
Change-Id: I24e7931f64867a4fb4e7b728c65faa6198e24aba
Reviewed-on: https://gerrit.libreoffice.org/4285
Reviewed-by: Khaled Hosny <khaledhosny@eglug.org>
Tested-by: Khaled Hosny <khaledhosny@eglug.org>
This reverts commit cef3f3aac2f7a372e796deac4ee3e8155c5eb697.
The previous commit addressed the real issue.
Change-Id: I802e5f19e4a4991c316135f3984a1b9a6533a104
I was overloading ApplyDXArray() with a HarfBuzz specific implementation
because the GenericSalLayout one was screwing right to left kerning, but
it seems to have broken left to right full justifications. Since
mnXOffset was introduced a bit earlier to fix a similar issue, it can
now be used here as well to minimize the possible side effects.
Seems to work fine for both left to right and right to left text now,
but at least one of my Arabic tests is regressing, so might need some
tweaking.
Change-Id: I1239b0ec77a4978f981a480400a6d01cda18af79
