libopc

Closed Task: missing iOS build for build 0.0.2 [794]

mfayez — Thu, 16 May 2013 10:31:19 GMT

the iOS video tutorial in the documentation section is using version 0.0.1 which is wrong as this version does not have mceTextReader_t data type.

please make a new build for iOS for version 0.0.2

I got the code and I am trying to make the build myself, if it worked fine please allow me to upload it.

best regards,
Mahmoud Fayez

Commented Feature: add Zip64 64bit support [165]

gemmell — Thu, 02 May 2013 00:49:41 GMT

Currently Zip64-based OPC container are not supported.
Comments: ** Comment from web user: gemmell **

Would be good to have.

New Post: Building libopc for armv7 with clang

valentinradu — Sat, 27 Apr 2013 18:23:21 GMT

Hey Florian,

Thanks for the input, works like a charm. Just one thing, you can't set the host in your config file so I had to hack it a little to get it to work (set it manually), I don't know if this is intended (or if there is a nicer way to do it) or not, but I though I should write it here if anybody has this problem in the future.

New Post: Building libopc for armv7 with clang

flr — Sat, 27 Apr 2013 17:04:13 GMT

Hi,

you need to define the platform in the Makefile.platform.xml. I use

<platform name="ios4-debug-gcc-i386" family="ios-debug-gcc-x86"

cc="/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/llvm-gcc-4.2"

ld="/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/ld"

ar="/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/ar"

cflags="-g -O0 -arch i386 -fno-exceptions -fvisibility=hidden -fstack-protector"

cflags_c="-std=c99" cflags_cpp="-fno-rtti"

cppflags="-D__IPHONE_OS_VERSION_MIN_REQUIRED=40300 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/"

ldflags="-framework Foundation -framework UIKit -framework CoreText -framework CoreGraphics -framework OpenGLES -framework QuartzCore -lstdc++"/>

<platform name="ios4-release-gcc-i386" family="ios-release-gcc-x86"

cc="/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang"

ld="/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld"

ar="/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ar"

cflags="-g -Os -arch i386 -fno-exceptions -fvisibility=hidden"

cflags_c="-std=c99" cflags_cpp="-fno-rtti"

cppflags="-DNDEBUG -D_NDEBUG -D__IPHONE_OS_VERSION_MIN_REQUIRED=40300 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/"

ldflags="-framework Foundation -framework UIKit -framework CoreText -framework CoreGraphics -framework OpenGLES -framework QuartzCore -lstdc++"/>

<platform name="ios4-debug-gcc-armv7" family="ios-debug-gcc-arm"

cc="/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang"

ld="/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld"

ar="/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ar"

cflags="-g -O0 -arch armv7 -fno-exceptions -fvisibility=hidden -mthumb"

cflags_c="-std=c99" cflags_cpp="-fno-rtti"

cppflags="-miphoneos-version-min=4.3 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk"

ldflags="-framework Foundation -framework UIKit -framework CoreText -framework CoreGraphics -framework OpenGLES -framework QuartzCore -lstdc++"/>

<platform name="ios4-release-gcc-armv7" family="ios-release-gcc-arm"

cc="/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang"

ld="/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld"

ar="/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ar"

cflags="-g -Os -arch armv7 -fno-exceptions -fvisibility=hidden -mthumb"

cflags_c="-std=c99" cflags_cpp="-fno-rtti"

cppflags="-DNDEBUG -D_NDEBUG -miphoneos-version-min=4.3 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk"

ldflags="-framework Foundation -framework UIKit -framework CoreText -framework CoreGraphics -framework OpenGLES -framework QuartzCore -lstdc++""/>

on my machine.

Let me know whether this works,

Florian

New Post: Building libopc for armv7 with clang

valentinradu — Sat, 27 Apr 2013 16:27:50 GMT

Hi,

Fist of all, thank you for this great lib. I'm trying to build it for armv7 but it seems it's not supported out of the box. I've tried to set the os/ver/toolchain/arch to ios4-debug-clang-armv7 with no luck. Also, it seems the config file only accepts debug for the clang toolchain. Is there a easy way to do it?

New Post: .rels xml missing header

DrLudwig — Sat, 30 Mar 2013 20:44:25 GMT

Hi Florian,
thank you for your reply. I'm using the compiled version libopc-sdk-darwin-debug/release-gcc-x64-0.0.3 and do not feel confident to compile the library myself at this stage.
If you don't mind could you please add this line:

opcContainerWriteUtf8Raw(out, _X('<?xml version="1" encoding="utf-8"?>'))

before your next release?
Thank you for this very useful library.
Regards,
Matthias

New Post: .rels xml missing header

flr — Sat, 30 Mar 2013 10:37:23 GMT

Hi, well --- it should not be a problem. But you can easily add the header in opcContainerWriteRels (container.c). Simply put a opcContainerWriteUtf8Raw(out, _X("<?xml version=....")); in there. Best, Florian

New Post: .rels xml missing header

DrLudwig — Thu, 28 Mar 2013 23:16:55 GMT

When I create a custom opc package using libopc on MacOS X and add a relationship with opcRelationAdd the produced .rels xml file does not have the usual xml header:
<?xml version= ...

This does not seem to be a problem, but is not equivalent to what microsoft is doing.

New Post: using in C#

connectsrini2011 — Sun, 10 Mar 2013 01:11:35 GMT

I do need this library to create a c# .net wrapper how to do it

New Post: .NET Wrapper

connectsrini2011 — Sun, 10 Mar 2013 01:07:16 GMT

Does a .NET Wrapper Exist and if not how to create a .NET Wrapper ( C# ) from object file library

New Post: .NET Wrapper (no SDK)

toddmain — Sat, 09 Feb 2013 01:40:11 GMT

Do you know if a .NET wrapper exists for libOPC? I'm working with WinRT, which doesn't support IO.Packaging. So it looks like libOPC may be the way to go, but I haven't a clue as to what do with C++/CLI stuff.

If a wrapper exists, could you point me to it? If not, how would one go about creating one? My needs are pretty simple - read-only and a rough estimation of IO.Packaging to load the streams (PackageParts, XML, images, etc.). No need for SDK type of mapping to named package parts.

Commented Feature: add Zip64 64bit support [165]

harikoduru — Thu, 24 Jan 2013 16:47:32 GMT

<p>Currently Zip64-based OPC container are not supported.</p>
Comments: ** Comment from web user: harikoduru **

We support this request as well.

New Post: Problem iterating relations

rebustiano — Tue, 22 Jan 2013 16:51:59 GMT

Well, sorry for the question, the real problem was at example code!!!!!!!!!!!!

In the second loop, "rel" must be compared with OPC_RELATION_INVALID instead of OPC_PART_INVALID.

Regards!

New Post: Problem iterating relations

rebustiano — Tue, 22 Jan 2013 16:32:18 GMT

Well, I have just fixed my problem but I think the solution is not "elegant".

I could see when a part has no relations opcRelationFirst return UINT_MAX as relation. Then:

 for(opcPart part=opcPartGetFirst(c);OPC_PART_INVALID!=part;part=opcPartGetNext(c, part)) {
		 //printf("%s;%s \n", part, opcPartGetType(c, part));
	   for(opcRelation rel=opcRelationFirst(c, part);
		 OPC_PART_INVALID!=rel; rel=opcRelationNext(c, part, rel)) 
      {
		   if (rel == UINT_MAX) break;
			...
			...
       }
}

As I said, I dont like the solution, Could somebody get de images "id" by other way or with a more elegant code?
Many Thanks!

New Post: Problem iterating relations

rebustiano — Tue, 22 Jan 2013 16:01:38 GMT

HI every one.

I am making a reader and render for docx files and using libopc to read it.

Well, I have a problem to get the images "id", then I decided get the image "Id" by the same way that opcContainerDump method is printing this information. For beginning I tried to print every relationship by using the code that I see in libopc documentation but the code is crashing...

opcContainer *c = opcContainerOpen(_X(filePath.c_str()),  OPC_OPEN_READ_ONLY,  NULL,  NULL);
if (c)
{
		
    for(opcPart part=opcPartGetFirst(c);OPC_PART_INVALID!=part;part=opcPartGetNext(c, part)) {
	   for(opcRelation rel=opcRelationFirst(c, part); OPC_PART_INVALID!=rel; rel=opcRelationNext(c, part, rel)) {
		   opcPart internal_target=opcRelationGetInternalTarget(c, part, rel);
		   const xmlChar *external_target=opcRelationGetExternalTarget(c, part, rel);
		   const xmlChar *target=(NULL!=internal_target?internal_target:external_target);
		   const xmlChar *prefix=NULL;
		   opc_uint32_t counter=-1;
		   const xmlChar *type=NULL;
		   opcRelationGetInformation(c, part, rel, &prefix, &counter, &type);        
		   if (-1==counter) { /* no counter after prefix */
			  printf("%s;%s;%s;%s\n", part, prefix, target, type);
		   } else {
			  printf("%s;%s%i;%s;%s\n", part, prefix, counter, target, type);
		   }
	   }
}
...
....

Any suggestion?

Many thanks and great library!

Commented Feature: add Zip64 64bit support [165]

rursem — Fri, 18 Jan 2013 21:47:17 GMT

<p>Currently Zip64-based OPC container are not supported.</p>
Comments: ** Comment from web user: rursem **

When using OPC from a C++ environment with large files, 64 bit support is needed. In our field we plan to use OPC for reservoir descriptions, which can easily exceed the 32 bit limit.

New Post: Large parts and Windows X64

dmendres — Tue, 08 Jan 2013 17:18:33 GMT

Well, duh, now that I submitted this, I see that Zip64 is not currently supported and there is an existing work item to add Zip64 support. The field set in the quoted code is the original zip header, for file sizes up to 0xFFFFFFFF. I just voted the work item up. Any comments on the difficulty of accomplishing this?

New Post: Large parts and Windows X64

dmendres — Tue, 08 Jan 2013 15:12:56 GMT

I have rebuilt libopc on Windows (VS2010) for X64 platform (I think!). It certainly is running in a 64-bit executable. However, I see that the part headers in zip.c appear to be hard-coded as unsigned int 32:

 && (4==opcZipRawWriteU32(io, rawState, compressed_size))  // compressed size
        && (4==opcZipRawWriteU32(io, rawState, uncompressed_size))  // uncompressed size

As expected, when I create a large part (12391552489), the recorded archive compressed size (3801617899) is incorrect, and is exactly the remainder of the original size modulo max unsigned int32:

12391552489%4294967295

3801617899

Now, Winzip knows the actual size of the uncompressed part, so I believe the deflated stream is written correctly, but the header is incorrect.

Have I built the X64 target incorrectly or is this a libopc limitation? I suspect the latter because of the 4 byte write quoted from zip.c, above.

Commented Issue: At unidentified conditions libopc fail with "Part /_rels/.rels does not exist.!\n" message [1074]

vitaly_v_ch — Tue, 08 Jan 2013 14:57:34 GMT

but unzip show "_rels/.rels" as archive member:

$ unzip -v 210648_summary_0_avg.xlsx
Archive: 210648_summary_0_avg.xlsx
Length Method Size Cmpr Date Time CRC-32 Name
-------- ------ ------- ---- ---------- ----- -------- ----
531 Defl:N 192 64% 1980-00-00 00:00 947bd5a8 _rels/.rels
702 Defl:N 359 49% 1980-00-00 00:00 9c87e49e docProps/core.xml
267 Defl:N 163 39% 1980-00-00 00:00 8f99c3e9 docProps/app.xml
...
$
Comments: ** Comment from web user: vitaly_v_ch **

Some hint:

I add following lines to findItem():

OPC_ASSERT(i==j);
*pos=i;
+ {
+ for (i=0; i<items; i++)
+ fprintf(stderr, "%s: key1='%s', ((opcContainerPart*)array_)[%u].name='%s'\n",
+ __func__, key1, i, ((opcContainerPart*)array_)[i].name);
+ }
return OPC_FALSE;

and get on stderr:

findItem: key1='_rels/.rels', ((opcContainerPart*)array_)[0].name='docProps/app.xml'
findItem: key1='_rels/.rels', ((opcContainerPart*)array_)[1].name='docProps/core.xml'
findItem: key1='_rels/.rels', ((opcContainerPart*)array_)[2].name='xl/sharedStrings.xml'
findItem: key1='_rels/.rels', ((opcContainerPart*)array_)[3].name='xl/styles.xml'
findItem: key1='_rels/.rels', ((opcContainerPart*)array_)[4].name='xl/workbook.xml'
findItem: key1='_rels/.rels', ((opcContainerPart*)array_)[5].name='xl/worksheets/sheet1.xml'
findItem: key1='_rels/.rels', ((opcContainerPart*)array_)[6].name='xl/worksheets/sheet10.xml'
findItem: key1='_rels/.rels', ((opcContainerPart*)array_)[7].name='xl/worksheets/sheet11.xml'
findItem: key1='_rels/.rels', ((opcContainerPart*)array_)[8].name='xl/worksheets/sheet2.xml'
findItem: key1='_rels/.rels', ((opcContainerPart*)array_)[9].name='xl/worksheets/sheet3.xml'
findItem: key1='_rels/.rels', ((opcContainerPart*)array_)[10].name='xl/worksheets/sheet4.xml'
findItem: key1='_rels/.rels', ((opcContainerPart*)array_)[11].name='xl/worksheets/sheet5.xml'
findItem: key1='_rels/.rels', ((opcContainerPart*)array_)[12].name='xl/worksheets/sheet6.xml'
findItem: key1='_rels/.rels', ((opcContainerPart*)array_)[13].name='xl/worksheets/sheet7.xml'
findItem: key1='_rels/.rels', ((opcContainerPart*)array_)[14].name='xl/worksheets/sheet8.xml'
findItem: key1='_rels/.rels', ((opcContainerPart*)array_)[15].name='xl/worksheets/sheet9.xml'
Part /_rels/.rels does not exist.!

So '_rels/.rels' really does not exist in array_. It's by design or it's misbehavior of libopc?

Commented Issue: At unidentified conditions libopc fail with "Part /_rels/.rels does not exist.!\n" message [1074]

vitaly_v_ch — Sun, 23 Dec 2012 09:53:08 GMT

In my application all calls to libopc are made from same thread. So all calls are properly mutexed :)

-pthread is artefact from main application.

all sample code you can extract from attachment XlsxEditor.zip. My sample code is stripped down from main application except that artifact :).