This has never been enabled during the open source history of
openoffice.org . Yet we have been building the code and the resource
file for it. Should I be surprised?
Change-Id: Iba8262f125d0ea3a35fa7f256a3cdbd353e598bc
Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk
have kept them, in order not to break external API (the automatic using declaration
is LO-internal).
Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
Moved portions from module i18npool, all of former i18nisolang1 library
that now is i18nlangtag. Included are languagetag, isolang and mslangid.
This i18nlangtag code is now even used by module comphelper, so
disentangling i18npool and making this an own module was needed to not
create circular module dependencies.
Change-Id: Ib887c3d6dde667403fd22d382310ba5f1a9b0015
"x-translate" entries are unused so remove them.
SFX.xcu: All entry use the same value, it is useless
to add this for all language. It's enough to add an
"en-US" entry and all local will use it's value.
Change-Id: I88d807a092f11d057ed6ee8809eb5d6851e87f95
This is first step to rework of graphic exporting. The idea is to
replace the exporter that works only for Draw/Impress and replace
it with a general exporter for any object. With this it will be
far easier to export objects as charts. Currently only Writer is
supported and only jpg/png.
Additionally, this commit introduces a new Export dialog which
supports setting the pixel width, height and DPI.
Change-Id: I7302b26bd432840d7ef0c3d2d2e13ff150cd2a07
AttributeError: 'NoneType' object has no attribute 'write' when trying
to print to stdout and sys.stdout has been set to None.
Change-Id: Icb571b9e910d4ec393dc1fd246f867c02d5ac8e5
We can now export a chart to odc when we are in chart edit mode from
Calc. I need to add support for it to Writer and Impress as well.
We can already open these files but copy&paste from the opened file
fails. The next step is then to add a new menu entry
Insert->Object->Chart from file
Change-Id: I14d1702e79517e7319a1929de2be5501d375885d
In theory we shouldn't have to do this any more now that we do test
against all possible format types in the first pass. But let's test
if my theory is right...
Change-Id: I70d73a99aec56a66deaeb3f942fd2641a2cc7f48
I did my best to check each and every one of them and rank them to the
best of my ability. Any mistakes are to be fixed as they are discovered.
Note that while working on this, I've noticed that we don't actually have
any real type detection codes for many of these format types, especially
the graphic file formats. If we ever have trouble loading any file type,
check if it's caused by not having any detection code for it, and if so,
we should write one for that file type. That said, my casual tests on
loading graphic files didn't cause any trouble.
Change-Id: I1398cbb72b2d4ccf75434a9aa0d2a5c5d17bdaad
The old type detection would only test file format types that are
relevant to the current document service. But this would not work
if the user tries to open an Excel document whose name ends with a
non-default extension (such as .tmp) from Writer UI.
To amend this, we need to test all possible format types that are
supported by all our modules regardless of the current module, but
prioritize them per current module.
TODO: The above scenario doesn't work yet. I still need to fix
the individual type detection services to get it to work.
Change-Id: I51dbdff28299aa64cedc6752b9ff82b96d5d79cf
Only applies to PropertyAttribute::REMOVEABLE, and all instances in comments.
All other instances of the misspelling have remained the same.
Example: AF_REMOVEABLE
Change-Id: I391f4101bbc3e06689318235a37d616065bc1686
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>
Using the autocorrect list of LibreOffice
extras/source/autotext/lang/en-US/acor/DocumentList.xml
Change-Id: I8b93969bc0742c2e95b8b7db3c4c37691e8d3657
Script: http://pastebin.ca/2327716
