Age | Commit message (Collapse) | Author |
|
Thus making the gtk+ backend more similar to the generic backend
in this regard; also be more strict about invalid monitors -> empty
screens.
Change-Id: Ia4f2e1205cb1d309fb1bb01f9631167339a3478e
|
|
This touches up lightly on e986d3e396174096abb46075bf7488677b9a35f9
Change-Id: If4d940433b27abec63a85c5975f5e9ebf672b79a
|
|
We shouldn't be trying to free the font table buffer when destroying the
blob, so pass NULL for destroy function instead of free(), and also use
HB_MEMORY_MODE_READONLY just to be safe.
Change-Id: I85b5a575249b4efc0f5799db205ee17cbeb66d22
|
|
Change-Id: I6ddeff7ae72693fd0951d71bd7b5444938bc7286
|
|
Change-Id: Iaec745dc1c8eb0614cc2fe1d70a94a00d18cc934
|
|
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
|
|
Change-Id: I78efebb576dffa8d39e98283feb9aab2186b5a39
|
|
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
|
|
X and Y offsets should only affect the position of the current glyph,
not any subsequent ones.
Change-Id: I9dd1576cbdbb36b70f1898dc52702c02c4e851af
|
|
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
|
|
...whereby some branding could be orverridden with information from a program/edition/
directory.
Change-Id: I7f9324678b09bc8069775dfcbda97be8e0618a91
|
|
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>
|
|
Change-Id: I969217263fdda3e61b38dc16f0a9251b745de885
Reviewed-on: https://gerrit.libreoffice.org/3652
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
|
|
Change-Id: I512e6332a632acf90e4f995fbc7fd19e7ef094ec
Reviewed-on: https://gerrit.libreoffice.org/3644
Tested-by: Ahmad Harthi <aalharthi@kacst.edu.sa>
Reviewed-by: Ahmad Harthi <aalharthi@kacst.edu.sa>
|
|
Change-Id: I1c6c43b73b22120b2f2985256896af214012f0ad
|
|
This Checkbox is shown in the File picker dialog and does not embed the file in the document, if checked.
Change-Id: I84fbc182cc9b432cd38ccb044c0479ced119d97f
Reviewed-on: https://gerrit.libreoffice.org/3602
Reviewed-by: Tor Lillqvist <tml@iki.fi>
Tested-by: Tor Lillqvist <tml@iki.fi>
|
|
Change-Id: Ied358faaf6ba1aecae4f61ff56e639752a2de664
|
|
let si-phonetic-dynamic survive libreoffice losing focus and regain it cycle
and still use surrounding text. It should be safe to report that we can provide
surrounding text but there isn't any during the time window when there is no
focus window, because the focus in event was received but it hasn't arrived yet
because that happens on a postuserevent.
Change-Id: I0481c42208953f2a0618aaed7b0d9e9f3e7bda07
|
|
i.e. false for "we can't provide context", and true for
"we can provide context, even if there isn't any"
Still looks to me that there's a bug in the si-phonetic-dynamic
im (or something in the stack) that assumes that returning
false once means it will always return false and give up
for ever
fix indent while I'm at it
Change-Id: I6df7f2689101250c33318db1fac5ec1b3e340566
|
|
Change-Id: I34c532dc7d1c71724a5c0e29c113f2d6510cc2d7
|
|
Since 360d6bf4fd1241af47f55648b7597fda3120390a the precompiled header for vcl
includes <rsc/rsc-vcl-shared-types.hxx> , so the KEY_SHIFT from there
interfered with the KEY_SHIFT here.
These magic values apparently are the "known" return values from
MapVirtualKey() called to translate (fixed) virtual key codes to scan codes,
suitably shifted and ORed with some flag bit(s). Whether such scan code values
really are constant in all Windows installations I have no idea, it does sound
a bit scary to me to assume they are. (If they are, why does <windows.h> then
not provide symbolic names for them?)
Change-Id: Ic18a8e1a8b7a95bb6b018382662944f6912e4734
|
|
Change-Id: I67e73438312f2a672e71762ee6707ec5d425bb47
|
|
makedepend relies on that
Change-Id: I6a166f65d25c2750c24bc7831d074c32f6524722
|
|
Change-Id: Ib316bf40bb9b9afeb5fbdf9281f2d3b9539e346f
|
|
When we are launching the printing dialog, we first draw the page using
drawinglayer to a metafile, and then render the metafile. Unfortunately, here
we did the real operation of allocating large bitmaps, and destroying them
again; all that just to throw all that away at the end of the operation.
The preview sets the mbOutput to false correctly, so we can just skip the
expensive parts.
Change-Id: Ice77d83100eba339602bbdf374fec8546d4d1e12
|
|
Change-Id: I8e9f70eb5d929c98b4379416c2259a74e31d587f
Reviewed-on: https://gerrit.libreoffice.org/3503
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
|
|
Change-Id: I400fad08c0ae7b6b34bad63693f54856867e4dac
Reviewed-on: https://gerrit.libreoffice.org/3502
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
|
|
Change-Id: Ib48a12e902f2311c295b2007f08f44dee28f431d
Reviewed-on: https://gerrit.libreoffice.org/3499
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
|
|
see https://gerrit.libreoffice.org/#/c/3367/
and Change-Id: I00c96fa77d04b33a6f8c8cd3490dfcd9bdc9e84a for details
Change-Id: I199a75bc4042af20817265d5ef85b1134a96ff5a
|
|
Change-Id: I7be27b049c4a482be256544c295a7aee89f81f57
|
|
correctly removed in 804e86170ff2570fd3826b4ac26d1c927e751ac3
but we will need it again soon
Change-Id: I52700cb4da0285bf08db20af2d7c314a37c4fee2
|
|
Make sure everything is using 16.16 fixed point values consistently.
Change-Id: Icdcd94775d3860d57bb446a3f237c31e35e0710a
Reviewed-on: https://gerrit.libreoffice.org/3573
Reviewed-by: Fridrich Strba <fridrich@documentfoundation.org>
Tested-by: Fridrich Strba <fridrich@documentfoundation.org>
|
|
Change-Id: Ic28c7922b0fab3b5a7ac1c0500a429539a4c29bc
|
|
HarfBuzz is an up to date, actively maintained OpenType layout engine,
while the ICU LayoutEngine we use now has been unmaintained for a
while now, and existing users are encouraged to switch to HarfBuzz.
This is work in progress, text layout mostly works, but the handling
of combining marks is broken and needs further work, so it is kept
optional for now, with SAL_USE_HARFBUZZ env variable to enable it at
runtime.
Change-Id: I07e698f7486379bae68329771695cd94d6e561b5
Reviewed-on: https://gerrit.libreoffice.org/3518
Reviewed-by: Fridrich Strba <fridrich@documentfoundation.org>
Tested-by: Fridrich Strba <fridrich@documentfoundation.org>
|
|
To be used in the next commit.
Change-Id: I6ee286d0c050a5ca650e7fb3692b0facccb5f0c0
Reviewed-on: https://gerrit.libreoffice.org/3517
Reviewed-by: Fridrich Strba <fridrich@documentfoundation.org>
Tested-by: Fridrich Strba <fridrich@documentfoundation.org>
|
|
Change-Id: Ifc8275276811ba24b62f93096e7cb98a5dbf658c
|
|
Change-Id: I2bb49bd85844d35301372b4f9d06f11db27fe9ea
|
|
|
|
Change-Id: Ifc4925feccea9c35654356120b157f27d7cbfd3b
|
|
Change-Id: I01995091350ed4a4edefa13ca6946d23062112a1
|
|
...apparently caused by 845456565db945ffd2a1551ab86446fcd1717021 "DO NOT use
internal headers of jpeg." The warning there "I am not sure if it is all right
to include parts of jpeg directly into our code" still holds, of course.
Change-Id: I4754dbcd9b2c3eafc64d32c3b83faa53cf913abd
|
|
They ARE NOT available when using system jpeg.
Apart of that, I am not sure if it is all right to include parts of jpeg
directly into our code.
Change-Id: Ic19a22e73094d452ffd072b819020e4a46256406
|
|
Change-Id: I098ad140d013f1bda057416b2e0622bc038d2a30
|
|
Change-Id: I921ba50f1d251489bfb56703247890f9ff23200f
|
|
Change-Id: I50014b227b07a4b7bff7b2569ec55409f371b38e
|
|
Change-Id: Ia00803c748cd40b7e2e6142a2802ea6e4e13f8fd
|