The iWork 2013 file format includes .iwa (iWork Archive) files stored within a .zip file. "IWA files are stored in Snappy's framing format, though they do not adhere rigorously to the spec. In particular, they do not include the required Stream Identifier chunk, and compressed chunks do not include a CRC-32C checksum." https://github.com/obriensp/iWorkFileFormat/blob/master/Docs/index.md#iwa
Is there an implementation of Snappy that can decompress files missing these components? If so, is there example code?
Examples of iWork files may be found at the bottom of this page: http://fileformats.archiveteam.org/wiki/IWA. For instance, unzipping file TestReport.pages.zip shows that it contains Index.zip, which contains .iwa files.
I tried decompressing the .iwa files using the Snappy for Windows command line tool here: http://snappy.angeloflogic.com/downloads/ . However, I received the error: "Found invalid data while decoding."
I do not yet have sample code because I do not know which implementation of Snappy I should base my code on.
Related
I'm programming a simple HTTP server in C. So far, my server only supports text/html. I'm trying to add more functionalities to it by supporting additional MIME types (more precisely: text /css, text/javascript, image/jpg, image/png, font/woff2). For html files, I simply used fseek() and ftell() to determine the size of the file and read(), write() to read the file into a buffer and send it to the client. Now, I have the following questions:
1.Can I treat js, css, and woff2 files the exact same as html files (figuring size, reading, and sending)?
2.For binary files (images), what differences am I expected to make? Can I still use fseek() and ftell() to determine the size? Let's say I used fread(), can I use the return value as the file length? Is fwrite() really better than write() for binary files? Do I have to encode the image file before sending (I checked the RFC but I can't find any definite answer)? Should I include the "Content-Transfer-Encoding", or is it optional?
Do I have to encode the image file before sending (I checked the RFC but I can't find any definite answer)? Should I include the "Content-Transfer-Encoding", or is it optional?
No you don't need any encoding, and, FWIW, there is no Content-Transfer-Encoding field in HTTP.
I have to work with a C/C++ build environment that drops intermediate files all over the place:
.i files containing the output of the C-preprocessor (roughly raw C)
.s files containing the input of the C-assembler
CEDET (I assume the semantic analyzer) eventually finds these files and attempts to index them. This results in jumping to .i files containing raw C for definitions and generally slowing down parsing and loading of the .semanticdb.
I never open these files in emacs, so they must be being loaded by the background analyser.
Is it possible to prevent the analyser from loading these files? I can't find any configuration options that define the file-types that are parsed by the background analyser.
If you never need C mode for these files, here's a quick fix:
(add-to-list 'auto-mode-alist '("\\.i\\'" . fundamental-mode))
(add-to-list 'auto-mode-alist '("\\.s\\'" . fundamental-mode))
The answer from abo-abo gave me the clues I needed. The grep implementation (used by EDE) of semantic-symref-perform-search uses auto-mode-alist to find matching files for a given semantic mode (based on the current buffer's mode - eg `c-mode) when trying to resolve symbols.
The final fix I used is to specifically eliminate the default entries in the auto-mode-alist using:
(delete '("\\.i\\'" . c-mode) auto-mode-alist)
(delete '("\\.ii\\'" . c++-mode) auto-mode-alist)
Adding fundamental-mode entries as suggested by abo-abo seems to work also, however I was concerned that since the c-mode entries were still in the list a change in implementation could result in them being reactivated.
I am looking for some input on how to programmatically convert mp4 files to fragmented f4f files with accompanying manifests.
I currently have an implementation for creating segmented MPEG2-TS files with accompanying manifest for Apples HLS, and want to create a similar piece of software for Adobes HDS.
My code is based on Libav (alternatively, ffmpeg), so I was hoping they had native support for muxing f4f files, but I have not been able to find any resources for it.
What I am specifically looking for:
How (if) the format is used in libav?
If there is any special requirements (such as the h264_mp4toannexb filter required for converting MP4 to MPEG2 TS)?
Any sample code (even if it's not using libav/ffmpeg)
An easy-to-read manifest specification.
I'm afraid you have to read mp4/f4f specification, and implementation it your self.
MP4 file format: ISO/IEC 14496-14
f4f file format: It is included in the f4v specification.(http://www.adobe.com/cn/devnet/f4v.html)
The code of mod_h264_streaming (http://h264.code-shop.com/trac) may be helpful.
I have three .asn files. After these three files are compiled by the asn.1 compiler, each file has a corresponding directory in the output folder. In each folder, there are many C source files that were generated by the asn.1 compiler. There is always a .c file which has the same name as the .asn file (except the extension name, i.e. test.asn and test.c). In this file, some functions are defined; like asn_alloc, asn_free etc.
So, there are three files implementing the asn_alloc and asn_free functions. I'll use all the generated C files in my C project.
The problem is, the asn_alloc function is defined in three places. This is the reason I'm getting the compiler error:
multiple definition of function
How do I deal with this problem? I think that editing the generated source file is not a good idea.
This problem is specific to the ASN.1 Tool you are using. With some ASN.1 Tools (such as the one at http://www.oss.com), you can either include all of the .asn files in the same compilation so that one .c file is generated with all names disambiguated, or you can use the -prefix xxx option on each compilation where xxx is different for each ASN.1 compilation thus causing the generated names to be prefixed with xxx, therefore not conflicting.
I am trying to understand the different file extensions for the pfxplus powerflex database. Could someone please help telling me briefly what each file is for?
.k1
.k2
.k3
...
.k13
.k14
.k15
.fd
.def
.hdr
.prc
.pc3
Data files:
OK, so .dat is the data file.
.k1 -> .k15 are index files.
These are the critical data files for runtime. (Combined with filelist.cfg or pffiles.tab similar to define what files are available overall).
.fd is the file definition, needed for compiling programs
.tag (which you did not mention) is needed only if you need to access field names at run time (such as using a generic report tool)
.def is the file definition in human readable form, and is not needed by any process but is produced so a programmer or user can understand the file structure.
Run time:
The .ptc files are the compiled threads interpreted by the powerflex runtime.
The .prc file is a resource file that is used at runtime in conjunction with the .ptc file - it defines how a character based program is to look in a gui environment in "g-mode". It was the cheap way to upgrade character based programs when windows first started getting popular usage.
.hdr and .pc3 escape me at the moment, but are vaguely familiar - .hdr is probably another data file used with compression or special field types for later versions of pfxplus. .pc3 may in fact be the .ptc files...