Build tools do not link against merged libraries but individual small
ones we need for this (gb_BUILD_HELPER_LIBS).
Change-Id: Ia765e11a93ed05d126334a3e146fb88e368954ac
IMHO there is no reason why they should be 0444. I have found no
explanation for it, either in the commit that introduced the bundled
dictionaries or in the related bug.
Change-Id: Ia42218a0d579ced5f17248a092eab2c61cb9005f
It turned out that ApplyDXArray() is need to apply advance width
adjustments after justification, so we can't just bypass it.
So I just copied GenericSalLayout::ApplyDXArray() and stripped it of
ICUism so it does not break with HarfBuzz, but I had to make
m_GlyphItems non-private, so I'm not sure this is the right approach.
Change-Id: I66d647c3590fdf912c39d0cf23ac72bcc7ca72c9
The 3rd parameter to hb_buffer_add_utf() should be the length of the
whole text not the current run, so that HarfBuzz can take the context
into account when shaping.
Change-Id: I9e4e928d40078c3e3667cfdb6d8f24bf6e58263d
No more second guessing if text width, we know that information already,
so pass it around instead of trying to re-create it.
Change-Id: I19faacbc309d38753c3c9f7214dfa0bf59cc66b5
Not that I'm a fan of Hungarian notation, but for the sake of
consistency. Fix some placement of opening braces along the way.
Change-Id: Id6ea758fd438a4040e7451430a0f3a166efdec43
GenericSalLayout::GetTextWidth() uses GlyphItem's mnNewWidth when
calculating text width, and though this seems logical (it is after all
the actual with the glyph is contributing to the all over advance
width), it results in shorter width calculation whenever glyph width
adjustment is involved, no idea why!
The #ifdef is there so that the ICU code path is not changed in anyway,
but all of this should be merged into GenericSalLayout when ICU is
gone.
Change-Id: I7cbde1675b78e87c142513eb52a13ee5fdc60617
Use local variables instead of altering the returned glyph positions
array, looks more cleaner this way.
Change-Id: Ibbcced57777010bd045668a99d7beb0618abe226
It turns out it is GenericSalLayout::ApplyDXArray() that is messing with
glyph advance widths trying to recalculate them. It is very old code (it
has been there since ICU were introduced back in 2002), but whatever
issue it is fixing, HarfBuzz does not need it.
Change-Id: I5c896d3f318e2f17d135f9eea599b917e04ed592
when you change the text direction it should update the numerical type but it dosen't.
this patch will get you out of edit mode before changing text direction and after finish the change it will get you in again
Change-Id: I5598fd9dab823c738a812537743695ec88690a24
Reviewed-on: https://gerrit.libreoffice.org/3629
Reviewed-by: Tor Lillqvist <tml@iki.fi>
Tested-by: Tor Lillqvist <tml@iki.fi>
New keywords can now simply be added to a static array rather than
adding a new "else if" blocks for each keyword.
Change-Id: Ib581b3e834a57e0dfa9d139bcb4ae7a0a52a5472
The ctor later will turn that reference to a pointer anyway, but the old
code made it easy to pass a String, get it implicitly converted to
OUString, and then we took the address of the temporary OUString, later
resulting in accessing already freed memory. Instead, take an OUString
pointer, and then the compiler will warn about a String* -> OUString*
conversion. Adapt one remaining caller accordingly.
Change-Id: I4084dea1d245f0c8919d6afe47c5f391729f6eaf
IMO Calling this method again is not required. The If Blocks returns
false when User Clicks "Cancel" Button in "Format Cell" Widget,
IMO on Cancel Their is no need to Update the table. And on Ok
SetAttrToSelectedCells method is called which inturn calls
UpdateTableShape() method.
Change-Id: I2bb0bb616cc978717a1494e01f257631aadd613c
Reviewed-on: https://gerrit.libreoffice.org/3391
Reviewed-by: Tor Lillqvist <tml@iki.fi>
Tested-by: Tor Lillqvist <tml@iki.fi>
Iterate over all selected cells, set appropriate alignment based on
current writing direction and alignment of the cell.
Don’t change alignment when cell is center aligned or justified.
and if alignment is right or left, change it respective to writing direction.
Change-Id: Ie98a46af97236ab4303d030f11bd167939dde32b
Reviewed-on: https://gerrit.libreoffice.org/3549
Reviewed-by: Tor Lillqvist <tml@iki.fi>
Tested-by: Tor Lillqvist <tml@iki.fi>
By removing the last two libs: nullcanvas and directx5canvas.
directx5canvas seems to be dead and nullcanvas don't have entries in scp2.
Change-Id: Ib8fc1da123f8374fb83192f14db730638213f564
Reviewed-on: https://gerrit.libreoffice.org/3626
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
Cleanup of source code:
- translated German to English
- removed useless comment decorations
- removed commented out code
- some reformatting of code
Change-Id: I71d5fdab8226d61bda9ac906bb82176dc11cafd2
Reviewed-on: https://gerrit.libreoffice.org/3643
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
My simple test file is finally valid but is still now shown in Excel.
There must be another bug in our exporter.
Change-Id: Ib55e5b32edc3a556e9081b3008df539275dc289b
This does not work yet as we have several validation errors in our
exported OOXML chart doc. I have to clean them up before the documents
are accepted by Excel.
Change-Id: I0bba64a9c6cab489199c8e6f04158fea7b953d0a
