Re: LibreOfficeLight / iOS

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<CGContextRef>(pBuffer);

    // the Size argument is irrelevant, I hope

    ScopedVclPtrInstance<VirtualDevice> pDevice(&aData, 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<UInt8>.
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 <jani@apache.org> 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 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.