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>
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>
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
Since 360d6bf4fd 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
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
see https://gerrit.libreoffice.org/#/c/3367/
and Change-Id: I00c96fa77d04b33a6f8c8cd3490dfcd9bdc9e84a for details
Change-Id: I199a75bc4042af20817265d5ef85b1134a96ff5a
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>
...apparently caused by 845456565d "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
The canBeRotated method was added to determine if a native rotation
can be performed for a graphics or not.
Change-Id: I026cf6fe4baa4d964d0a2c2b6e36c3b15aa91549
Rotation for PNG and GIF format perform by exporting and importing
of the Graphic. This is a "fallback" way to perform graphic rotation
and the easiest to do for lossless raster formats.
Change-Id: I31efad9106b5cfbd1d7c6c5063726c455d05f934
Support for reading/writing of Exif image metadata. Currently only
orientation is implemented, but support for other tags can be added.
Jpeg lossless transformations - currently only lossless rotation is
supported, but others can be added when needed.
Additionally GraphicNativeTransform and GraphicNativeMetadata has
been added. The responsibillity of GraphicNativeTransform is to
provide graphic transformations (like rotation) on native data and
the purpose is to be as lossless as possible in transformations.
GraphicNativeMetadata is a class for reading metadata which is
contained in a native data graphic stream. For now both support
only Jpeg.
Change-Id: I3e67cd3e7f5386746bcd1f0bfd2b90f5fe834b92
jpeg.cxx/hxx contains classes JpegWriter and JpegReader which are
considered private. Split this two classes and other related
functions into its own files.
Change-Id: I41c1139b30a4dc19e03b2232dfe0986cc05d0c08
Now all these usages were removed from LO.
Change-Id: I8a7233db20abdcdbb18428ad4004c78cc516a0e6
Reviewed-on: https://gerrit.libreoffice.org/3326
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
Move the native methods out to a separate AppSupport class so that they aren't
in our "experimenal" Desktop app's namespace. Don't hardcode the name of that
class in the native code, but have the app register the class to which the
damage callbacks should be done.
Possibly the AppSupport and Bootstrap classes should be combined. Later.
Also, the "android" part of the package name is superfluous; it is
Android-specific code, no information gained by having an "android" part in
the package name.
Change-Id: Iddf55c8034ead7693887ace8438deb002c5eea9f
