Re: LibreOfficeLight / iOS

[jan iversen]

Hi

On 5 January 2018 at 06:35, Jon Nermut  wrote:

> Hi Jan,
> I've added the UIScrollView into the mix - you can now scroll and zoom and
> it's nicely re-rendering at higher res when zooming. It surprisingly good
> for a first cut. Havent tried it on device yet.
>
> One question - is there meant to be rendered page backgrounds/edges?
> Currently the entire background is white, with no page edges, so the pages
> kind of run into each other on a large doc.
>
My intention was to use the whole size for the text, to maximise that text
viewable, and thus no need for edges. However it would be nice if the
program has something like night settings as in iBook.

>
> The glitchiness problem on the tile edges was a wrong hardcoded DPI
> constant in salgdicommon.cxx:
>
> -rDPIX = rDPIY = 200; // FIXME
> +// This matches the default for VirtualDevice, and the calculations
> +// in the paint tile methods. (SwViewShell::PaintTile and elsewhere)
> +rDPIX = rDPIY = 96;
>
I will look into this as well

>
> I was compensating for this with a scaling of 2.0, which isn't exactly
> 200/96, hence the small problems at the tile edges.
>
> All good now, and fixing this meant less messing around with the scaling
> etc.
>

As you might have seen, I have made several commits on master, solving the
libassuan issue as well as other issues you reported, I am right now
working on the dylib and solar mutex issues.

rgds
jan I
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: LibreOfficeLight / iOS

[jan iversen]

> Sorry for not being clear - please disable GPGME for iOS (for both
> build and host). It currently serves no useful purpose on that
> platform, and is certainly not necessary for building.
>

You were perfectly clear, and it is disabled for the iOS build (== host),
but the tools (build-tools) is done for MACOSX and at least svidl demands
libassuan, I will try to find a way to disable GPGME for MACOSX when cross
compiling.

thanks.
rgds
jan I.

>
> HTH,
>
> -- Thorsten
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: LibreOfficeLight / iOS

[Thorsten Behrens]

jan iversen wrote:
>  I have just checked my different build environments:
> 
> MACOS (works)
> 
Yes. It's supposed to work there.

> iOS (tools build but cannot run due to missing libassuan dylib)
> 
> 
> config_build.mk
> 
> export BUILD_TYPE=... LIBGPGERROR LIBASSUAN GPGMEPP ...
> 
> export ENABLE_GPGMEPP=TRUE
> 
Sorry for not being clear - please disable GPGME for iOS (for both
build and host). It currently serves no useful purpose on that
platform, and is certainly not necessary for building.

HTH,

-- Thorsten


signature.asc
Description: Digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: LibreOfficeLight / iOS

[jan iversen]

>
> Ah, for makefiles, use ENABLE_GPGMEPP to check if that's
> available. HAVE_FEATURE_GPGME is for source code, and defined in
> config_host/config_gpgme.h
>

 I have just checked my different build environments:

MACOS (works)

config_host.mk

export BUILD_TYPE=... LIBGPGERROR LIBASSUAN GPGMEPP ...

export ENABLE_GPGMEPP=TRUE


config_host/config_gpgme.h

#define HAVE_FEATURE_GPGME 1


All builds and works




iOS (tools build but cannot run due to missing libassuan dylib)


config_build.mk

export BUILD_TYPE=... LIBGPGERROR LIBASSUAN GPGMEPP ...

export ENABLE_GPGMEPP=TRUE


config_build/config_gpgme.h

#define HAVE_FEATURE_GPGME 1

config_host.mk

export BUILD_TYPE=... ... (no build of GPG related matters)

export ENABLE_GPGMEPP=


config_host/config_gpgme.h

#define HAVE_FEATURE_GPGME 0



This looks quite OK to me, but when building sfx2, I get the error that
svidl cannot load libassuan. The libassuan dylib exit in

workdir_for_build/UnpackedTarball/libassuan/src/.libs/libassuan.0.dylib


it does not exist in instdir_for_build. Do I need to do something special
in external/libassuan to copy it (I thought it worked automatically) ?


when I copy libassuan.0.dylib, libgpgme.11.dylib and libgpg-error.0.dylib
it works. I am confused because I see other dylib being copied
automatically.


Thanks in advance.

reds

Jan I.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: LibreOfficeLight / iOS

[Thorsten Behrens]

jan iversen wrote:
> Please advice me, how to disable GPGME for both build and host
> configuration.
> 
Ah, for makefiles, use ENABLE_GPGMEPP to check if that's
available. HAVE_FEATURE_GPGME is for source code, and defined in
config_host/config_gpgme.h

Cheers,

-- Thorsten


signature.asc
Description: Digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: LibreOfficeLight / iOS

[jan iversen]

Manually adding BRAND_SHARE_SUBDIR=share

> to fundamentalrc allowed me to render a tile using the CGContext based
> code in the unit test, and save it to a png. Woohoo!
>
> I'm not sure where that should be added?
>
It is generated in iOS/CustomTarget_iOS_setup.mk line 54-64, once I get my
things to compile again, I will have a closer look.

rgds
jan I
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: LibreOfficeLight / iOS

[jan iversen]

libassuan is part of the gpg4libre subsystem, and rather certainly not
> useful on iOS. I suggest to disable that, like on Android (there's a
> feature check define now, HAVE_FEATURE_GPGME).
>

Thanks for the info, I can see HAVE_FEATURE_GPGME is being defined in
configure.ac, but it not declared in
config_host/config_features.h.in or config_host.mk.in

so it seems not to be available to clang or make ?

I cannot see how to disable it, I need to disable it both for iOS and for
cross-toolset (that runs on normal Mac).

My problem is svidl (part of cross-toolset), when called it tries to load
libassuan.

Funny thing is that when I build for MAC I have no problem.

Please advice me, how to disable GPGME for both build and host
configuration.

Thanks in advance.
rgds
jan I.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: LibreOfficeLight / iOS

[Thorsten Behrens]

jan iversen wrote:
> I have just updated my master, and now I see your problem with libassuan,
> which I am trying to solve. It is being build locally but not copied to the
> right place. I did a couple of commits yesterday to a.o. include your idea
> on how to make LIBRARY_PATH relative, thanks for that.
> 
libassuan is part of the gpg4libre subsystem, and rather certainly not
useful on iOS. I suggest to disable that, like on Android (there's a
feature check define now, HAVE_FEATURE_GPGME).

Cheers,

-- Thorsten


signature.asc
Description: Digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: LibreOfficeLight / iOS

[Jon Nermut]

The tile rendering exception was caused by this path:

OUString VclBuilderContainer::getUIRootDir()

{

OUString sShareLayer(
"$BRAND_BASE_DIR/$BRAND_SHARE_SUBDIR/config/soffice.cfg/");

rtl::Bootstrap::expandMacros(sShareLayer);

return sShareLayer;

}

In my build $BRAND_SHARE_SUBDIR
was not defined.
Manually adding BRAND_SHARE_SUBDIR=share
to fundamentalrc allowed me to render a tile using the CGContext based code
in the unit test, and save it to a png. Woohoo!

I'm not sure where that should be added?



On Mon, Jan 1, 2018 at 9:44 PM, Jon Nermut  wrote:

> Well a framework is effectively dylib *in a bundle*. For swift there is
> some special module stuff baked in too. So I also moved all the resources
> to the framework (hence the changes I made to look up the framework bundle
> instead of the main bundle to find the rc / unorc etc files.
>
> You're probably right that you should be able to spit out a dylib or a
> framework from ld - I've just spent *way* too much of my professional life
> fighting xcode on this kind of stuff that I'll always go with what the IDE
> says. Which these days is frameworks. But if you can get the .mk to produce
> a dylib and be able to use it the dev process will be better whether you
> use a framework to encapsulate the library or not.
>
> Does the dylib load at all on the device? Or does it give image not found
> error, or symbol not found? It's very sensitve to paths - both where the
> dylib is in the bundle (if you put it in the embed section it will be under
> /Frameworks/), and the runtime search path setting, which needs to include
> that location.
>
> NB our app which has an embedded framework wrapping the pdfium lib, has
> been in the appstore with that framework for at least a year.
>
> > My problem was more how to use the returned array in order to render it
> effectively
>
> So that was using the paintTile function? What did you pass into it - a
> CGContextRef or a byte array? Or is paintTile the wrong function to be
> calling entirely??
> If a CGContextRef (which is what it has to be, given this)
>
>
> static void doc_paintTile(LibreOfficeKitDocument* pThis,
>
>   unsigned char* pBuffer,
>
>   const int nCanvasWidth, const int nCanvasHeight,
>
>   const int nTilePosX, const int nTilePosY,
>
>   const int nTileWidth, const int nTileHeight)
>
> {
>
> ...
>
>
> #if defined(IOS)
>
> SystemGraphicsData aData;
>
> aData.rCGContext = reinterpret_cast(pBuffer);
>
> // the Size argument is irrelevant, I hope
>
> ScopedVclPtrInstance pDevice(, Size(1, 1),
> DeviceFormat::DEFAULT);
>
>
> pDoc->paintTile(*pDevice.get(), nCanvasWidth, nCanvasHeight,
>
> nTilePosX, nTilePosY, nTileWidth, nTileHeight);
>
> #else
>
> then the overall way to get a UIImage is as per the POC code in
> DocumentController - set up a Image CGContext, do the render, then call
> UIGraphicsGetImageFromCurrentImageContext
>
> UIGraphicsBeginImageContextWithOptions(CGSize(width:
> canvasWidth, height: canvasHeight), false, 1.0)
>
>
>
> let ctx = UIGraphicsGetCurrentContext()
>
> print(ctx)
>
> let ptr = unsafeBitCast(ctx, to: UnsafeMutablePointer.
> self)
>
> print(ptr)
>
> doc.paintTile(pBuffer:ptr,
>
>   canvasWidth: Int32(canvasWidth),
>
>   canvasHeight: Int32(canvasHeight),
>
>   tilePosX: tilePosX,
>
>   tilePosY: tilePosY,
>
>   tileWidth: tileWidth,
>
>   tileHeight: tileHeight)
>
>
>
> let image = UIGraphicsGetImageFromCurrentImageContext()
>
> UIGraphicsEndImageContext()
>
> The unsafeBitCast in there is really just the reverse, (and just as
> horriable) of the reinterpret_cast in doc_paintTile
>
> Once you have a UIImage you can blat it to the screen in a UIImageView, or
> save it to disk etc.
> From memory to get a UIImage from a byte array you have to go via CGImage
>
> This is some sample code that goes from a byte buffer to a CGImage, then
> to a UIImage
>
> let buffer = FPDFBitmap_GetBuffer(bitmap)
>
> let bitsPerComponent = 8
>
> let bitsPerPixel = 32
>
> let bytesPerRow = 4 * width
>
> let colorSpaceRef = CGColorSpaceCreateDeviceRGB()
>
> let intent = CGColorRenderingIntent.defaultIntent
>
> let bitmapInfo = CGBitmapInfo.byteOrder32Little.union(CGBitmapInfo(rawValue:
> CGImageAlphaInfo.noneSkipFirst.rawValue))
>
> let cgImage = CGImage(width: width, height: height, bitsPerComponent:
> bitsPerComponent, bitsPerPixel: bitsPerPixel, bytesPerRow: bytesPerRow,
> space: colorSpaceRef, bitmapInfo: bitmapInfo, provider: provider!, decode:
> nil, shouldInterpolate: false, intent: intent)
>
>
> return UIImage(cgImage: cgImage, scale: 0.5, orientation:
> UIImageOrientation.up)
>
>
>
> I can 

Re: LibreOfficeLight / iOS

[Jon Nermut]

Well a framework is effectively dylib *in a bundle*. For swift there is
some special module stuff baked in too. So I also moved all the resources
to the framework (hence the changes I made to look up the framework bundle
instead of the main bundle to find the rc / unorc etc files.

You're probably right that you should be able to spit out a dylib or a
framework from ld - I've just spent *way* too much of my professional life
fighting xcode on this kind of stuff that I'll always go with what the IDE
says. Which these days is frameworks. But if you can get the .mk to produce
a dylib and be able to use it the dev process will be better whether you
use a framework to encapsulate the library or not.

Does the dylib load at all on the device? Or does it give image not found
error, or symbol not found? It's very sensitve to paths - both where the
dylib is in the bundle (if you put it in the embed section it will be under
/Frameworks/), and the runtime search path setting, which needs to include
that location.

NB our app which has an embedded framework wrapping the pdfium lib, has
been in the appstore with that framework for at least a year.

> My problem was more how to use the returned array in order to render it
effectively

So that was using the paintTile function? What did you pass into it - a
CGContextRef or a byte array? Or is paintTile the wrong function to be
calling entirely??
If a CGContextRef (which is what it has to be, given this)


static void doc_paintTile(LibreOfficeKitDocument* pThis,

  unsigned char* pBuffer,

  const int nCanvasWidth, const int nCanvasHeight,

  const int nTilePosX, const int nTilePosY,

  const int nTileWidth, const int nTileHeight)

{

...


#if defined(IOS)

SystemGraphicsData aData;

aData.rCGContext = reinterpret_cast(pBuffer);

// the Size argument is irrelevant, I hope

ScopedVclPtrInstance pDevice(, Size(1, 1),
DeviceFormat::DEFAULT);


pDoc->paintTile(*pDevice.get(), nCanvasWidth, nCanvasHeight,

nTilePosX, nTilePosY, nTileWidth, nTileHeight);

#else

then the overall way to get a UIImage is as per the POC code in
DocumentController - set up a Image CGContext, do the render, then call
UIGraphicsGetImageFromCurrentImageContext

UIGraphicsBeginImageContextWithOptions(CGSize(width:
canvasWidth, height: canvasHeight), false, 1.0)



let ctx = UIGraphicsGetCurrentContext()

print(ctx)

let ptr = unsafeBitCast(ctx, to: UnsafeMutablePointer.
self)

print(ptr)

doc.paintTile(pBuffer:ptr,

  canvasWidth: Int32(canvasWidth),

  canvasHeight: Int32(canvasHeight),

  tilePosX: tilePosX,

  tilePosY: tilePosY,

  tileWidth: tileWidth,

  tileHeight: tileHeight)



let image = UIGraphicsGetImageFromCurrentImageContext()

UIGraphicsEndImageContext()

The unsafeBitCast in there is really just the reverse, (and just as
horriable) of the reinterpret_cast in doc_paintTile

Once you have a UIImage you can blat it to the screen in a UIImageView, or
save it to disk etc.
>From memory to get a UIImage from a byte array you have to go via CGImage

This is some sample code that goes from a byte buffer to a CGImage, then to
a UIImage

let buffer = FPDFBitmap_GetBuffer(bitmap)

let bitsPerComponent = 8

let bitsPerPixel = 32

let bytesPerRow = 4 * width

let colorSpaceRef = CGColorSpaceCreateDeviceRGB()

let intent = CGColorRenderingIntent.defaultIntent

let bitmapInfo =
CGBitmapInfo.byteOrder32Little.union(CGBitmapInfo(rawValue:
CGImageAlphaInfo.noneSkipFirst.rawValue))

let cgImage = CGImage(width: width, height: height, bitsPerComponent:
bitsPerComponent, bitsPerPixel: bitsPerPixel, bytesPerRow: bytesPerRow,
space: colorSpaceRef, bitmapInfo: bitmapInfo, provider: provider!, decode:
nil, shouldInterpolate: false, intent: intent)


return UIImage(cgImage: cgImage, scale: 0.5, orientation: UIImageOrientation
.up)



I can see this stuff is used and working on Android, but there are quite a
few #ifdef IOS in there haven't been exercised in a while... And it's using
quite a different rendering mechanism drawing to a CGContext compared to
drawing to a byte buffer.




On Mon, Jan 1, 2018 at 8:31 PM, jan iversen  wrote:

> Happy new year, very interesting work.
>
> I have just updated my master, and now I see your problem with libassuan,
> which I am trying to solve. It is being build locally but not copied to the
> right place. I did a couple of commits yesterday to a.o. include your idea
> on how to make LIBRARY_PATH relative, thanks for that.
>
> > try the -r flag which is for prelinking. you can see that in the .mk
> file
>
>> Couldn't get that to do anything. I also tried -flto=thin which
>> supposedly can 

Re: LibreOfficeLight / iOS

[jan iversen]

Happy new year, very interesting work.

I have just updated my master, and now I see your problem with libassuan,
which I am trying to solve. It is being build locally but not copied to the
right place. I did a couple of commits yesterday to a.o. include your idea
on how to make LIBRARY_PATH relative, thanks for that.

> try the -r flag which is for prelinking. you can see that in the .mk file

> Couldn't get that to do anything. I also tried -flto=thin which supposedly
> can do incremental linking, but again little effect
>

Look in iOS/CustomTarget_iOS_prelink.mk, there you will find

$(IOSLD) -r -ios_version_min 11.1 \

-syslibroot $(MACOSX_SDK_PATH) \

-arch `echo $(CPUNAME) |  tr '[:upper:]' '[:lower:]'` \

-o $(IOSOBJ) \

$(WORKDIR)/CObject/ios/source/LibreOfficeKit.o \

`$(SRCDIR)/bin/lo-all-static-libs` \

$(call gb_StaticLibrary_get_target,iOS_kitBridge)

$(AR) -r $(IOSKIT) $(IOSOBJ)

which does prelinking (different from incremental linking). You can see it
generated and .o file, which is then put into an archive.


> Nah it would be very difficult if not impossible to get a swift Framework
> built through make - one thing that I've learnt in iOS development is don't
> fight XCode. You'ld end up just calling xcodebuild anyway, which still
> needs the project set up correctly.
>
??? xcode runs perfect on the command line, so I do not understand why you
say it is impossible.


>
>
* The linking of the framework takes just as long as the app did. But once
> you have it built, as long as you don't touch the framework, rebuilds of
> the app are fast
>
This is as expected. The framework is basically a dylib so of course
linking to that is a lot faster.

I am still not convinced making a framework is a better solution than just
linking a dylib directly, at least I do not see the advantages and at least
one disadvantage, one more xcode project to maintain.


> * It's only been tested on the simulator. Needs some more stuffing about
> to link the correct lib for device.
>

dylib works very well in the simulator, my first test on my iPad (iOS 11.2)
did not turn out very well. I am also looking into another problem, it
seems that the App Store, still only allows upload of statically linked

*** The way it's set up in the app at the moment with 3 schemes isn't as it
> should be - you should have just one scheme, and use Configuration is for
> debug/release, and platform/arch for simulator vs device. This will work ok
> in the app once the framework is configured to link the correct .a file.
> Which I will sort out if you move forward with this
>

The reason for using different schemes, is that the xcode doc recommends
it, and it make the use simpler, since you just have to select a scheme.

Why do you think just having 1 scheme is better ?


> * I built out the Swift wrappers to cover all of the LibreOfficeKit
> functions. Have a look at Document.swift in particular. The next step would
> be to make an extension of Document to make iOS friendly methods for eg
> rendering to a UIImage
>

It is a different approach, but one I like, we do however still need the C
file.



> * I tried to get a tile rendering both in the test and the app. No good.
>
> Firstly I was trying to pass a byte buffer to paintTile as per the method
> signature, but it force casts that param to a CGContextRef a couple of
> layers down...
> But even after creating one of those to render into a image, it crashes
> with an uncaught exception of type 
> com::sun::star::container::NoSuchElementException
> (see pic of stack trace below)
> Which took me deep into debugging core LibreOffice, which I didn't really
> want to be, and was a bit frustrating. Maybe I'm missing some init code, or
> passing the wrong params.
> Feels like it might be bitrot of this tiling code that was written as a
> POC in 2015 or so? I wonder when the last time it worked was. You mentioned
> that you couldn't get it working either?
>
My problem was more how to use the returned array in order to render it
effectively.

The paintTile code is used both in the android version (see core/android)
and the online (separate git repo), so it works.

You might have run into a problem with swift delivering a false type of
array.


> Anyway, I really think splitting into a Framework is the way to go - I
> think the rendering problems are probably independent of this.
> It provides a good separation between app and library, and makes the app
> be able to be pure swift.
> It would certainly make using LOK in another app much much easier, than
> trying to unpick the example app.
>
Which example app ?

The old example app have been removed because it was very outdated.

keep up the good work, I will get around to integrate part of it soon.

rgds
jan I.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org

Re: LibreOfficeLight / iOS

[jan iversen]

try the -r flag which is for prelinking. you can see that in the .mk file

And of course a debug version contains tons of symbols in order for the
debugger to be able to do its work.


> iOS has allowed dylibs since iOS 8 and the introduction of Swift. In fact
> you can't produce a static lib with Swift, only a dylib.
> For our Pdfium wrapper we produce a static lib out of the Pdfium code
> itself, and link that in a framework project with the swift wrappers, to
> produce a dylib which is a swift module that can be imported into an app.
> Beside the linking benefits this then gives you a nice encapsulated library
> that is easy to consume from swift.
>
that was my first attempt but the apple developers said no, will try to
scan through the doc again.


> If I have time over the next couple of days I'll have a go at creating a
> framework to see if it does actually behave as I expect.
>
or a lot easier simply change the .mk to build a .dylib instead of the .a
thr .o file within both should be identical.

rgds
jan i

-- 
Sent from My iPad, sorry for any misspellings.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: LibreOfficeLight / iOS

[Jon Nermut]

Hi Jan,
The way I understand it is that the static libs, the .a files, aren't
actually linked yet - they are just an archive of .o object files collected
together.
When you link the app with the static lib it has to do a full read of the
symbols in the .a file and write the relevant ones into the executable.
There are 1.3 million symbols in the .a file (from nm libKit_X86_64_debug.a
| wc -l )
Adding -print_statistics to the linker flags gives this:

   ld total time:  894.4 seconds ( 100.0%)
 option parsing time:   11.0 milliseconds (   0.0%)
  object file processing:0.1 milliseconds (   0.0%)
 resolve symbols:  612.3 seconds (  68.4%)
 build atom list:0.0 milliseconds (   0.0%)
 passess:  486.3 milliseconds (   0.0%)
write output:  281.6 seconds (  31.4%)
pageins=447127, pageouts=2622, faults=3099715
processed   7 object files,  totaling 476,732 bytes
processed   2 archive files, totaling 456,642,248 bytes
processed  32 dylib files
wrote output filetotaling 324,771,884 bytes

Eg most of the time is spent reading symbols from the .a file, and then
writing them into the executable.
I also played around of using ld independantly of XCode and just trying to
link the .a file with no app and no swift involved - times were about the
same.
So to improve the linking of the .a file I think the main game would be
reducing the number of symbols in the .a. Probably not that practical.

So what I think you will get with a Framework project is actually linking
the .a file, seperately to the application executable. That means you won't
have that full link every time you build the app, but only when the
framework needs to build. That's the theory, anyway.

iOS has allowed dylibs since iOS 8 and the introduction of Swift. In fact
you can't produce a static lib with Swift, only a dylib.
For our Pdfium wrapper we produce a static lib out of the Pdfium code
itself, and link that in a framework project with the swift wrappers, to
produce a dylib which is a swift module that can be imported into an app.
Beside the linking benefits this then gives you a nice encapsulated library
that is easy to consume from swift.

If I have time over the next couple of days I'll have a go at creating a
framework to see if it does actually behave as I expect.

Cheers

Jon


On Sat, Dec 30, 2017 at 2:43 AM, jan iversen  wrote:

> Please do not misunderstand my comments, I am open to any enhancements
> especially on the linking process of the app...but I would like to see a
> benefit of the changes.
>
> rgds
> jan I.
>
> On 29 December 2017 at 09:36, Jon Nermut  wrote:
>
>> Thanks for the reply Jan.
>>
>> My main point about BridgeLOKit was that you don't really need to add
>> another FFI on top of the existing LibreOfficeKit.h FFI.
>> Swift can import and use the existing _LibreOfficeKit /
>> _LibreOfficeKitClass and _LibreOfficeKitDocument /
>> _LibreOfficeKitDocumentClass structs and their functions just fine. Swift
>> actually has excellent C integration (and non-existent C++). To do so I
>> just added:
>>
>> #define LOK_USE_UNSTABLE_API 1
>>
>> #import "../../../include/LibreOfficeKit/LibreOfficeKit.h"
>>
>> Into lokit-Bridging-Header.h, and the struct types mentioned above are
>> usable directly within Swift without anymore C needed
>> - LibreOfficeKitWrapper.swift is an example of using the functions from
>> these structs directly, and wrapping the C struct pointers in swift
>> classes, making them encapsulated and easier to use.
>> The exception being the lok_init functions, which need to be included and
>> called from within a C file.
>>
>> >> The LIBRARY_SEARCH_PATH should be overwritten by the xcconfig file,
>> but I will need to check that.
>>
>> Oh, I couldn't find it... where is it supposed to be generated to? I
>> changed the the path settings in LibreOfficeLight.xcodeproj like this:
>>
>> - LIBRARY_SEARCH_PATHS = /Users/jani/LO/core/ios/generated/;
>> + LIBRARY_SEARCH_PATHS = $PROJECT_DIR/../generated/;
>>
>> I tried a few settings on the linking, couldn't make it better. Need to
>> find a way to work out what its doing... I'll have more of a play.
>> My suggestion is to split the C integration, and it's swift wrappers,
>> into a separate Framework project, and let that produce a dylib.
>> That should link pretty much instantly to the app, and should only
>> rebuild and link when the libreoffice lib changes, or the code in the
>> Framework
>>
>> Cheers
>>
>> Jon
>>
>>
>> On Fri, Dec 29, 2017 at 6:38 PM, jan iversen  wrote:
>>
>>> Hi
>>>
>>> adding dev list to reply, so that others might benefit from the info.
>>>
>>> Hope you don't mind the unsolicited email, I figured you were the guy to
 talk to about this from the git commits.

>>> I am working actively on creating a version of LO for the iPad.
>>>
>>> So I got it compiling via lode, with just a couple of hitches (had to

Re: LibreOfficeLight / iOS

[jan iversen]

Hi

adding dev list to reply, so that others might benefit from the info.

Hope you don't mind the unsolicited email, I figured you were the guy to
> talk to about this from the git commits.
>
I am working actively on creating a version of LO for the iPad.

So I got it compiling via lode, with just a couple of hitches (had to
> install libassuan, had to make sure to use the make out of lode, and there
> is a hard coded LIBRARY_SEARCH_PATH to /Users/jani/... in the ios project
> file)
>
I do not understand why you had to install extra libraries. I work on high
sierra with xcode 9 and have not installed that library.

The LIBRARY_SEARCH_PATH should be overwritten by the xcconfig file, but I
will need to check that.

There are 2 projects, but I assume you talk about the kit project?

>
> 1. The app doesnt actually attempt to render yet? Were you planning on
> using CATiledLayer for that? I've used it a couple of times (for PDFs)...
> it's fun
>

No it doesn’t. As you probably have seen the render function is near empty,
I am strugling to find out what the tiled calls returns and how to use that
in the swift app.

2. The static lib, and the compiled app, are pretty fat. (At least in debug
> for the simulator - ~400mb, I havent tried the release build yet). Too fat
> to embed in my app, it would have to be a separate app. Any insight as to
> whether this could ever be cut down to a reasonable size?
>
Well is it actually quite reduced. LO is simply big.

3. The link time on the app is outrageously slow at the moment - at least
> on my macbook pro - I guess this is related to the size and number of
> symbols in the static lib. That's what the dummy.c file is all about? Needs
> to be quarantined from the app somehow.  Perhaps by keeping it in a
> Framework project? Or cutting down its size. I was too scared to turn on
> LTO...
>
The link time is my biggest problem, linking the kit is a fraction of
linking the app, and It seems to be the swift interface that is the problem.

dummy.c is to link without the kit, and it is automatically quarantined,
look in build phases, where you will see it is not being compiled.

4. Just wondering the reasoning for starting a new C interface into
> LibreOfficeKit (eg BridgeLOkit_* )?
>
How else would you make a C/C++ interface for swift ?

I had success in talking to the main LibreOfficeKit.h file directly from
> swift by including it in the bridging file. Using it directly would take
> away a lot of duplication needed to flesh out BridgeLOkit. Granted the main
> C api isnt that friendly to use, but IMHO it would be better to do the
> wrapping and making the API friendly on the Swift side, rather than another
> layer of C, which then still needs swift friendly classes around it.
> The main problem is with the way LibreOfficeKitInit works (which seems
> weird...), for which I reused BridgeLOkit_Init and added a func to get
> the pointer to kit out.
> See the attached LibreOfficeKitWrapper.swift file - it has just a couple
> wrapped functions done but you can see what I mean. Needs the rest filled
> in and memory handling done.
>
Functions not declared in the bridge are unlikely to work in swift
(according to the swift documentation).


> I've done this before for Pdfium - which also has a C based FFI. We
> created a framework called PdfiumSwift which had swift classes like
> PDFDocument, PDFPage etc which wrapped the C interface and made consuming
> it easy in Swift. We hooked the memory management off the swift deinit()
> etc.  It used an internal private module to consume the C API so it was
> just the Swift API exposed outside of the framework / module.
>
this is basically the same the kit project does, except it does not use
classes.

rgds
jan i

>
> Once the basic wrapping is done, then these classes provide a good place
> to add stuff like converting the raw tiles into iOS friendly bitmaps etc.
>
> Anyway, good job on getting it this far, and happy new year.
>
> Cheers
>
>
> Jon Nermut
>
-- 
Sent from My iPad, sorry for any misspellings.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: LibreOfficeLight / iOS

[Sophia Schröder]

BTW:

from the marketing perspective (where I came from) I love the name you 
gave your babe:


I would also love to have two apps, for Android the existing "Viewer" 
what it isn't anymore with the new possibilities for editing e.g. and 
for iOS your awesome work, both as "LibreOfficeLight".


Given they have mainly the same functionalities and maybe have some less 
or more differences here and there.



Am 29.12.2017 um 16:43 schrieb jan iversen:
Please do not misunderstand my comments, I am open to any enhancements 
especially on the linking process of the app...but I would like to see 
a benefit of the changes.


rgds
jan I.

On 29 December 2017 at 09:36, Jon Nermut > wrote:


Thanks for the reply Jan.

My main point about BridgeLOKit was that you don't really need to
add another FFI on top of the existing LibreOfficeKit.h FFI.
Swift can import and use the existing _LibreOfficeKit /
_LibreOfficeKitClass and _LibreOfficeKitDocument /
_LibreOfficeKitDocumentClass structs and their functions just
fine. Swift actually has excellent C integration (and non-existent
C++). To do so I just added:

#define LOK_USE_UNSTABLE_API 1

#import "../../../include/LibreOfficeKit/LibreOfficeKit.h"


Into lokit-Bridging-Header.h, and the struct types mentioned above
are usable directly within Swift without anymore C needed
- LibreOfficeKitWrapper.swift is an example of using the functions
from these structs directly, and wrapping the C struct pointers in
swift classes, making them encapsulated and easier to use.
The exception being the lok_init functions, which need to be
included and called from within a C file.

>> The LIBRARY_SEARCH_PATH should be overwritten by the xcconfig file, but 
I will need to check that.

Oh, I couldn't find it... where is it supposed to be generated to?
I changed the the path settings in LibreOfficeLight.xcodeproj like
this:

-LIBRARY_SEARCH_PATHS = /Users/jani/LO/core/ios/generated/;
+LIBRARY_SEARCH_PATHS = $PROJECT_DIR/../generated/;

I tried a few settings on the linking, couldn't make it better.
Need to find a way to work out what its doing... I'll have more of
a play.
My suggestion is to split the C integration, and it's swift
wrappers, into a separate Framework project, and let that produce
a dylib.
That should link pretty much instantly to the app, and should only
rebuild and link when the libreoffice lib changes, or the code in
the Framework

Cheers

Jon


On Fri, Dec 29, 2017 at 6:38 PM, jan iversen > wrote:

Hi

adding dev list to reply, so that others might benefit from
the info.

Hope you don't mind the unsolicited email, I figured you
were the guy to talk to about this from the git commits.

I am working actively on creating a version of LO for the iPad.

So I got it compiling via lode, with just a couple of
hitches (had to install libassuan, had to make sure to use
the make out of lode, and there is a hard coded
LIBRARY_SEARCH_PATH to /Users/jani/... in the ios project
file)

I do not understand why you had to install extra libraries. I
work on high sierra with xcode 9 and have not installed that
library.

The LIBRARY_SEARCH_PATH should be overwritten by the xcconfig
file, but I will need to check that.

There are 2 projects, but I assume you talk about the kit project?


1. The app doesnt actually attempt to render yet? Were you
planning on using CATiledLayer for that? I've used it a
couple of times (for PDFs)... it's fun


No it doesn’t. As you probably have seen the render function
is near empty, I am strugling to find out what the tiled calls
returns and how to use that in the swift app.

2. The static lib, and the compiled app, are pretty fat.
(At least in debug for the simulator - ~400mb, I havent
tried the release build yet). Too fat to embed in my app,
it would have to be a separate app. Any insight as to
whether this could ever be cut down to a reasonable size?

Well is it actually quite reduced. LO is simply big.

3. The link time on the app is outrageously slow at the
moment - at least on my macbook pro - I guess this is
related to the size and number of symbols in the static
lib. That's what the dummy.c file is all about? Needs to
be quarantined from the app somehow.  Perhaps by keeping
it in a Framework project? Or cutting down its size. I was
too scared to turn on LTO...

The link time is my biggest problem, linking the kit is a
fraction of linking 

Re: LibreOfficeLight / iOS

[jan iversen]

Please do not misunderstand my comments, I am open to any enhancements
especially on the linking process of the app...but I would like to see a
benefit of the changes.

rgds
jan I.

On 29 December 2017 at 09:36, Jon Nermut  wrote:

> Thanks for the reply Jan.
>
> My main point about BridgeLOKit was that you don't really need to add
> another FFI on top of the existing LibreOfficeKit.h FFI.
> Swift can import and use the existing _LibreOfficeKit /
> _LibreOfficeKitClass and _LibreOfficeKitDocument /
> _LibreOfficeKitDocumentClass structs and their functions just fine. Swift
> actually has excellent C integration (and non-existent C++). To do so I
> just added:
>
> #define LOK_USE_UNSTABLE_API 1
>
> #import "../../../include/LibreOfficeKit/LibreOfficeKit.h"
>
> Into lokit-Bridging-Header.h, and the struct types mentioned above are
> usable directly within Swift without anymore C needed
> - LibreOfficeKitWrapper.swift is an example of using the functions from
> these structs directly, and wrapping the C struct pointers in swift
> classes, making them encapsulated and easier to use.
> The exception being the lok_init functions, which need to be included and
> called from within a C file.
>
> >> The LIBRARY_SEARCH_PATH should be overwritten by the xcconfig file, but
> I will need to check that.
>
> Oh, I couldn't find it... where is it supposed to be generated to? I
> changed the the path settings in LibreOfficeLight.xcodeproj like this:
>
> - LIBRARY_SEARCH_PATHS = /Users/jani/LO/core/ios/generated/;
> + LIBRARY_SEARCH_PATHS = $PROJECT_DIR/../generated/;
>
> I tried a few settings on the linking, couldn't make it better. Need to
> find a way to work out what its doing... I'll have more of a play.
> My suggestion is to split the C integration, and it's swift wrappers, into
> a separate Framework project, and let that produce a dylib.
> That should link pretty much instantly to the app, and should only rebuild
> and link when the libreoffice lib changes, or the code in the Framework
>
> Cheers
>
> Jon
>
>
> On Fri, Dec 29, 2017 at 6:38 PM, jan iversen  wrote:
>
>> Hi
>>
>> adding dev list to reply, so that others might benefit from the info.
>>
>> Hope you don't mind the unsolicited email, I figured you were the guy to
>>> talk to about this from the git commits.
>>>
>> I am working actively on creating a version of LO for the iPad.
>>
>> So I got it compiling via lode, with just a couple of hitches (had to
>>> install libassuan, had to make sure to use the make out of lode, and there
>>> is a hard coded LIBRARY_SEARCH_PATH to /Users/jani/... in the ios project
>>> file)
>>>
>> I do not understand why you had to install extra libraries. I work on
>> high sierra with xcode 9 and have not installed that library.
>>
>> The LIBRARY_SEARCH_PATH should be overwritten by the xcconfig file, but I
>> will need to check that.
>>
>> There are 2 projects, but I assume you talk about the kit project?
>>
>>>
>>> 1. The app doesnt actually attempt to render yet? Were you planning on
>>> using CATiledLayer for that? I've used it a couple of times (for PDFs)...
>>> it's fun
>>>
>>
>> No it doesn’t. As you probably have seen the render function is near
>> empty, I am strugling to find out what the tiled calls returns and how to
>> use that in the swift app.
>>
>> 2. The static lib, and the compiled app, are pretty fat. (At least in
>>> debug for the simulator - ~400mb, I havent tried the release build yet).
>>> Too fat to embed in my app, it would have to be a separate app. Any insight
>>> as to whether this could ever be cut down to a reasonable size?
>>>
>> Well is it actually quite reduced. LO is simply big.
>>
>> 3. The link time on the app is outrageously slow at the moment - at least
>>> on my macbook pro - I guess this is related to the size and number of
>>> symbols in the static lib. That's what the dummy.c file is all about? Needs
>>> to be quarantined from the app somehow.  Perhaps by keeping it in a
>>> Framework project? Or cutting down its size. I was too scared to turn on
>>> LTO...
>>>
>> The link time is my biggest problem, linking the kit is a fraction of
>> linking the app, and It seems to be the swift interface that is the problem.
>>
>> dummy.c is to link without the kit, and it is automatically quarantined,
>> look in build phases, where you will see it is not being compiled.
>>
>> 4. Just wondering the reasoning for starting a new C interface into
>>> LibreOfficeKit (eg BridgeLOkit_* )?
>>>
>> How else would you make a C/C++ interface for swift ?
>>
>> I had success in talking to the main LibreOfficeKit.h file directly from
>>> swift by including it in the bridging file. Using it directly would take
>>> away a lot of duplication needed to flesh out BridgeLOkit. Granted the main
>>> C api isnt that friendly to use, but IMHO it would be better to do the
>>> wrapping and making the API friendly on the Swift side, rather than another
>>> layer of C, which then still needs 

Re: LibreOfficeLight / iOS

[jan iversen]

On 29 December 2017 at 09:36, Jon Nermut  wrote:

> Thanks for the reply Jan.
>
> My main point about BridgeLOKit was that you don't really need to add
> another FFI on top of the existing LibreOfficeKit.h FFI.
> Swift can import and use the existing _LibreOfficeKit /
> _LibreOfficeKitClass and _LibreOfficeKitDocument /
> _LibreOfficeKitDocumentClass structs and their functions just fine. Swift
> actually has excellent C integration (and non-existent C++). To do so I
> just added:
>
> #define LOK_USE_UNSTABLE_API 1
>
> #import "../../../include/LibreOfficeKit/LibreOfficeKit.h"
>
> The reason I added a C layer is two fold:
1) I needed one to make the init call anyway.
2) I got several problems using the kit pointer, and calling functions
directly, it was clear that a lot of the calls was not converted correctly,
e.g. swift does naturally not know about the something special strings in
LO.

So in total I preferred supplying a bridgeheader, which tells exactly what
are tested and will work.


> >> The LIBRARY_SEARCH_PATH should be overwritten by the xcconfig file, but
> I will need to check that.
>
> Oh, I couldn't find it... where is it supposed to be generated to? I
> changed the the path settings in LibreOfficeLight.xcodeproj like this:
>
Look in the .mk files in iOS.


> I tried a few settings on the linking, couldn't make it better. Need to
> find a way to work out what its doing... I'll have more of a play.
> My suggestion is to split the C integration, and it's swift wrappers, into
> a separate Framework project, and let that produce a dylib.
> That should link pretty much instantly to the app, and should only rebuild
> and link when the libreoffice lib changes, or the code in the Framework
>

I do not see a real difference between a framework (which is basically a
library and a header file) and the current kit project ?

dylib files would be real preferencial, but how do you get those to work in
iOS. iOS demand static libraries.

rgds
jan I.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: LibreOfficeLight / iOS

[Jon Nermut]

Thanks for the reply Jan.

My main point about BridgeLOKit was that you don't really need to add
another FFI on top of the existing LibreOfficeKit.h FFI.
Swift can import and use the existing _LibreOfficeKit /
_LibreOfficeKitClass and _LibreOfficeKitDocument /
_LibreOfficeKitDocumentClass structs and their functions just fine. Swift
actually has excellent C integration (and non-existent C++). To do so I
just added:

#define LOK_USE_UNSTABLE_API 1

#import "../../../include/LibreOfficeKit/LibreOfficeKit.h"

Into lokit-Bridging-Header.h, and the struct types mentioned above are
usable directly within Swift without anymore C needed
- LibreOfficeKitWrapper.swift is an example of using the functions from
these structs directly, and wrapping the C struct pointers in swift
classes, making them encapsulated and easier to use.
The exception being the lok_init functions, which need to be included and
called from within a C file.

>> The LIBRARY_SEARCH_PATH should be overwritten by the xcconfig file, but
I will need to check that.

Oh, I couldn't find it... where is it supposed to be generated to? I
changed the the path settings in LibreOfficeLight.xcodeproj like this:

- LIBRARY_SEARCH_PATHS = /Users/jani/LO/core/ios/generated/;
+ LIBRARY_SEARCH_PATHS = $PROJECT_DIR/../generated/;

I tried a few settings on the linking, couldn't make it better. Need to
find a way to work out what its doing... I'll have more of a play.
My suggestion is to split the C integration, and it's swift wrappers, into
a separate Framework project, and let that produce a dylib.
That should link pretty much instantly to the app, and should only rebuild
and link when the libreoffice lib changes, or the code in the Framework

Cheers

Jon


On Fri, Dec 29, 2017 at 6:38 PM, jan iversen  wrote:

> Hi
>
> adding dev list to reply, so that others might benefit from the info.
>
> Hope you don't mind the unsolicited email, I figured you were the guy to
>> talk to about this from the git commits.
>>
> I am working actively on creating a version of LO for the iPad.
>
> So I got it compiling via lode, with just a couple of hitches (had to
>> install libassuan, had to make sure to use the make out of lode, and there
>> is a hard coded LIBRARY_SEARCH_PATH to /Users/jani/... in the ios project
>> file)
>>
> I do not understand why you had to install extra libraries. I work on high
> sierra with xcode 9 and have not installed that library.
>
> The LIBRARY_SEARCH_PATH should be overwritten by the xcconfig file, but I
> will need to check that.
>
> There are 2 projects, but I assume you talk about the kit project?
>
>>
>> 1. The app doesnt actually attempt to render yet? Were you planning on
>> using CATiledLayer for that? I've used it a couple of times (for PDFs)...
>> it's fun
>>
>
> No it doesn’t. As you probably have seen the render function is near
> empty, I am strugling to find out what the tiled calls returns and how to
> use that in the swift app.
>
> 2. The static lib, and the compiled app, are pretty fat. (At least in
>> debug for the simulator - ~400mb, I havent tried the release build yet).
>> Too fat to embed in my app, it would have to be a separate app. Any insight
>> as to whether this could ever be cut down to a reasonable size?
>>
> Well is it actually quite reduced. LO is simply big.
>
> 3. The link time on the app is outrageously slow at the moment - at least
>> on my macbook pro - I guess this is related to the size and number of
>> symbols in the static lib. That's what the dummy.c file is all about? Needs
>> to be quarantined from the app somehow.  Perhaps by keeping it in a
>> Framework project? Or cutting down its size. I was too scared to turn on
>> LTO...
>>
> The link time is my biggest problem, linking the kit is a fraction of
> linking the app, and It seems to be the swift interface that is the problem.
>
> dummy.c is to link without the kit, and it is automatically quarantined,
> look in build phases, where you will see it is not being compiled.
>
> 4. Just wondering the reasoning for starting a new C interface into
>> LibreOfficeKit (eg BridgeLOkit_* )?
>>
> How else would you make a C/C++ interface for swift ?
>
> I had success in talking to the main LibreOfficeKit.h file directly from
>> swift by including it in the bridging file. Using it directly would take
>> away a lot of duplication needed to flesh out BridgeLOkit. Granted the main
>> C api isnt that friendly to use, but IMHO it would be better to do the
>> wrapping and making the API friendly on the Swift side, rather than another
>> layer of C, which then still needs swift friendly classes around it.
>> The main problem is with the way LibreOfficeKitInit works (which seems
>> weird...), for which I reused BridgeLOkit_Init and added a func to get
>> the pointer to kit out.
>> See the attached LibreOfficeKitWrapper.swift file - it has just a couple
>> wrapped functions done but you can see what I mean. Needs the rest filled
>> in and memory handling done.