The l10n-for-node code does not work in the app. Instead of loading
the required JSON files at run-time, include all those translations
that seem complete enough as JavaScript code in the bundle.js. Use a
manaully curated list of translations, in a Perl script that generates
the JavaScript code in question.
Change-Id: I45d5cda477140ee63bb3fc8d9f1f4260bcdb97a7
docker run .... -e "extra_params=....." .....
For example it makes sense to start loolwsd without SSL, when you test
or develop. In this case the syntax is: -e "extra_params=--o:ssl.enable=false"
Change-Id: Iaa9eafc1e1d3f2d24009321760d1b7d6a9998450
And also:
* Hint the compiler to warn about the missing callbacks.
* Add few missing ones.
* Update the bundled headers.
Change-Id: I8d31363eaaea289e8a517c0b9b1142b33ce3027e
The locale / language tag dance is a bit confusing. Let's hope it now
works sanely.
Without this change, if I as a test in Xcode set the LANG environment
variable when running the app to "de", to match the case where the
user is using their device in a German locale, and then open a
non-trivial .odt document, close it, and open it again, I get an
assertion failure in sw, in SwXPageStyle::GetPropertyValues_Impl().
(Note that the LANG environment variable is not set by the system on
iOS; in this app LANG is just an arbitrary (but familiar) name for an
environment variable used only when debugging in Xcode. Maybe I should
have called it something else to avoid confusing code readers who
might think it has the same meaning as in POSIX systems.)
The above assertion failure does not happen if I don't set LANG. I
don't really fully understand the convoluted mechanisms involved, but
explicitly re-setting the <comphelper/lok.hxx> concept of (global)
language tag each time before opening a document seems to help. Note
that if I set LANG to just "de", the code then later while handling
setView() calls in ChildSession::loadDocument(), sets it to "de-DE"
anyway. But that doesn't seem to harm.
Change-Id: Ic697ed44b4ace488782ebee3aa2e7610bb02e93c
If the document-container has an explicit style attribute, then this
breaks Calc (only Writer was tested before). This restores the correct
Writer/Calc/Impress behavior when the setting is false and keeps correct
behavior with Writer when the setting is true.
Change-Id: I310660e88af4407e521529ec41b5dcb604108bd9
I could not figure out any sane way to access the correct .json files,
or data constructed from them by the Objective-C code, at run-time in
the iOS app. The l10n-for-node stuff that gets used in a normal Online
is not suitable at all as it wants to use XMLHttpRequest.
Thus I am working on changes to loleaflet that will include the
translations in the bundle.js when building for iOS. (Or Android,
presumably, once we get there.) There won't be any need to load the
correct .json files separately.
Change-Id: Ifd72b4077f3634c34dd2c2d84c0a2554459c86b6
In the mobile app, we don't run loleaflet.html through any filter that
would replace strings like <!--%DOCUMENT_CONTAINER_TOP%-->. We need to
produce a proper loleaflet.html at build time, using m4 for MOBILEAPP
conditionals.
Without this small fix, the loleaflet.html page ended up looking
extremely weird (all white document area), with nothing working.
It's not too easy to customize CSS, so move the top position of the
document container to loleaflet.html, where it's convenient to handle
this.
JS can dynamically query if the menu item should be there, similar to
the about dialog.
Change-Id: I4b2799a41f8ad31e3a9b4983fd1947d2e0363a2b
In addition:
- add methods to transport the certificate chain, signing
certificate and signing certificate to WSD
- add conversion of PEM cert. format to DER
- add transporting the certificate chain to the LO core
- run the signing function with the signing cert. and the
private key
Change-Id: I1a005e88cacbd81144df40d315197561401db427
Reviewed-on: https://gerrit.libreoffice.org/63156
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
This adds handling of signature status (manually request for the
status or as a callback) in WSD.
In addition prepare support for signing of document, but don't yet
trigger the actual LOKit function (needs the JS building blocks
set up first to know how to handle the payload - certificate and
private key)
Change-Id: Ic76baa5847bb52adde616338187d5979e0093c6d
Reviewed-on: https://gerrit.libreoffice.org/62533
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
Was moved before the poll in my
75438baa70.
Change-Id: I0ec99c0c1433d2e5d631720f003905cbd18206aa
Reviewed-on: https://gerrit.libreoffice.org/63052
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
