jaketmp / epub-quicklook Goto Github PK

I started using JTPepub's -creators method in the Spotlight importer, but noticed it returns an array of odd things.

It seems to return pairs of elements - an actual name followed by the role attribute for each creator. Except in the no creators case where it returns an array of just one empty string.

If we wanted to keep it for the Spotlight importer, then a better thing to return would either be an empty array, or just an array of all the creator values. i.e. skip the role attributes. I'd be tempted to make it query dc:contributors as well and put them in the same array. The Spotlight kMDItemContributors (?) attribute doesn't care about the order of the values.

Some of the test books (e.g. metadata.epub) have no cover at all.

The cover detection logic seems to display a broken webkit image icon for these books.

FAIL is not a helpful error message, need to log some more useful info.

The plugin is totally dead in Lion - alas so is Xcode for now...

Need to escape < > & &c.

I downloaded the .zip of this repository, but I don't see the epub.qlgenerator files. Instead I get folders with .c and .h and .m files. Do I need to compile this somehow? I tried $ make but that didn't work...

I don't know how the download files are currently produced. At some point it will be useful to include the Spotlight importer in the download - either the zip could contain both bundles, or the zip could contain .pkg installers, or...

Dunno what's best or easiest! One benefit of an installer is that it does things right for less technical users.

I note the Codex qlgenerator and mdimporter come with a .pkg installer.

As in #44, cover thumbnails seem to be broken again. This is worse because Mojave's Books app now generates thumbnails well, which this quicklook blocks.

How do the code signing requirements in Mountain Lion effect Spotlight / QuickLook plug-ins. - I can't find any good documentation for this at them moment - may still be under NDA.

It does not work. This error appears in the Console when trying to refresh icon view in Finder:

6/18/13 9:48:02.657 AM com.apple.quicklook.satellite[35126]: [QL] Computing (null) raised 'launch path not accessible'

I have 10.8.4. Installed by copying the files trough symlinks in DMG.

I can't see what's caused this, but a bunch of tests are failing because the JTPepub objects are "randomly" nil.

I think they're nil because mimetype (inside openEPUBfile) is wrong - NSlogging of mimetype shows:

Mar 2 21:43:03 aluminium otest[23787]: mimetype application/epub+zip�
Mar 2 21:43:03 aluminium otest[23787]: mimetype application/epub+zip2007/ops
Mar 2 21:43:03 aluminium otest[23787]: mimetype application/epub+zipctions
Mar 2 21:43:03 aluminium otest[23787]: mimetype (null)

I tried using NULL instead of my mmapped I/O stuff, no change.

Something's up, I think with memory somewhere. I think the init methods for ZipArchive are screwy - self = [self init] for example. Deleting the (useless) init method might help. Also you must call [self release] on failures, not [self dealloc]. The unit tests call setUp and tearDown for every test case, so they do exercise memory quite a bit.

I'm not sure what the best way of debugging memory problems like this is in Xcode...

Probably being drawn as black text. The background is also black...

After indexing epubs (I literally have tens of thousands) the searches work in Spotlight.
I'm a datascientist so if I type the word "heteroscedasticity", epubs appear. But just like with PDF's I'd like te be able to select te "kind" of document. So if I type: "kind:pdf heteroscedasticity" Spotlight only shows the PDF's with that word.

However when I type: "kind:epub heteroscedasticity" it doesn't find any epubs with that word.

I think they worked in 10.10.1, but since 10.10.2 book covers appear as a "broken link" in the QL preview window.

The covers still appear on the custom Finder previews.

Can you please add the two GDataXMLNode files to your repo?

It would make building a little simpler, especially if any patches to it are needed.

The interfaces in JTPepub and ZipArchive need unit-tests.

At some point it is probably worth tagging a new release and putting up a new download file.

A Lion-compatible spotlight plugin would be a nice and obvious thing to add.

I suspect adding an indexer would be straightforward - another target using the JTPepub class etc.

We are declaring an imported UTI of 'org.idpf.epub' for ePub documents - but this is blessed by neither Apple nor the IDPF.

Once either steps-up with an official UTI we need to use that.

Would this be possible? All the iBooks ePubs are located in:

~/Library/Containers/com.apple.BKAgentService/Data/Documents/iBooks/Books

ls -l in the mounted DMG shows:

lrwxr-xr-x   1 cjr   cjr       29 10 Mar 12:04 QuickLook -> /Users/jake/Library/QuickLook
lrwxr-xr-x   1 cjr   cjr       29 10 Mar 12:04 Spotlight -> /Users/jake/Library/Spotlight

Should work for you, but not everyone else!

When browsing through a couple of epub files in Finder with the cursor keys and Quick Look opened, the title is updated for each selected file but the cover shown remains the one of the epub selected/displayed first. Moreover, covers show a small question mark in a blue square with a white border.

Since Gitub removed all the "Downloads" tabs, there is no way to download the pre-built binary any more. Please consider making it available elsewhere.

I don't really understand all the scheme stuff, but while looking at Archiving I noticed that various compiler settings were different between the QL and MDI targets. Can they be shared somehow? Seems daft to edit them twice.

The QL Info.plist seems not to include a min OS version; the MDL one does (and it might be wrong).

Any ideas?

quicklook only parses/finds the first <meta> tag in an .opf file when looking for <meta name="cover" content="..."/>. An .opf file can have multiple <meta> tags so if the cover is not the first then the cover will not be displayed.

Thanks for the great work!

What's the license file for the source code? Can I use it in other ePub related projects?

I foolishly created a book with a cover image filename containing a space. This is written into the OPF (by Sigil) as:

<item href="Images/Dune%20Messiah.jpg" id="cover-image" media-type="image/jpeg" />

JTPepub's -cover method is unable to open the image, as it tries to open that literal name.

The filename in the zip file really does have a space:

95667  05-03-12 18:53   OEBPS/Images/Dune Messiah.jpg

The bug is that href values are URIs (not paths) which need decoding in order to be 'openable'. (So -textFromManifestItem: has the same problem.)

Is it possible to produce thumbnails of the covers like the Quicklook Video plugin is able to https://github.com/Marginal/QLVideo ?

ePub 3 completely changes the manner in which covers and metadata may be declared.

The BetterZipQL.qlgenerator clashes (i.e. gets used instead of) with the epub.qlgenerator on Snow Leopard, but not Lion. I've got Snow Leopard in a VM and can reproduce this.

It looks like they're claiming to support files with the .epub extension in their Info.plist:

<dict>
    <key>UTTypeConformsTo</key>
    <array>
        <string>public.zip-archive</string>
        <string>com.pkware.zip-archive</string>
    </array>
    <key>UTTypeDescription</key>
    <string>Zip Archive</string>
    <key>UTTypeIconFile</key>
    <string>Zip</string>
    <key>UTTypeIdentifier</key>
    <string>com.macitbetter.zip-archive</string>
    <key>UTTypeTagSpecification</key>
    <dict>
        <key>public.filename-extension</key>
        <array>
            <string>pk3</string>
            <string>pk4</string>
            <string>nth</string>
            <string>xpi</string>
            <string>swc</string>
            <string>epub</string>
        </array>
    </dict>
</dict>

I don't understand the Mac's UT system, but this seems to override the epub.qlgenerator's use of the epub extension and org.idpf.epub-container.

Hacking the <string>epub</string> line out of their Info.plist seems to work, but is an unreasonable thing to do IMO.

For Kindle users, possible to make simple compatibility with mobi files format?

Currently there are three contributor roles extracted from the ebook metadata.

1. editors
2. illustrators
3. translators

It would be nice to have a few more such as cover designer, printer, book designer, compositor or reviewer. A complete list of the available roles can be seen here http://www.loc.gov/marc/relators/relaterm.html.

Example for cover designer:

<dc:contributor opf:file-as="Glazer-Naude, Ludvik" opf:role="cov">Ludvik Glazer-Naude</dc:contributor>

Example for printer:

<dc:contributor opf:role="prt">Ebner &amp; Spiegel</dc:contributor>

Example for compositor:

<dc:contributor opf:file-as="Reischmann, Barbara" opf:role="cmt">Barbara Reischmann</dc:contributor>