jaketmp / epub-quicklook Goto Github PK
View Code? Open in Web Editor NEWNOTE: Not working in Mojave and later! ePub quicklook and spotlight plugins for Mac OS X.
License: BSD 3-Clause "New" or "Revised" License
NOTE: Not working in Mojave and later! ePub quicklook and spotlight plugins for Mac OS X.
License: BSD 3-Clause "New" or "Revised" License
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.
Thanks for the great work!
What's the license file for the source code? Can I use it in other ePub related projects?
Probably being drawn as black text. The background is also black...
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?
At some point it is probably worth tagging a new release and putting up a new download file.
The interfaces in JTPepub and ZipArchive need unit-tests.
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 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.
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.
Need to escape < > &
&c.
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.
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.
ePub 3 completely changes the manner in which covers and metadata may be declared.
For Kindle users, possible to make simple compatibility with mobi files format?
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.
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 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 ?
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.
Currently there are three contributor roles extracted from the ebook metadata.
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 & Spiegel</dc:contributor>
Example for compositor:
<dc:contributor opf:file-as="Reischmann, Barbara" opf:role="cmt">Barbara Reischmann</dc:contributor>
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...
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.
The plugin is totally dead in Lion - alas so is Xcode for now...
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.
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.
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.
Would this be possible? All the iBooks ePubs are located in:
~/Library/Containers/com.apple.BKAgentService/Data/Documents/iBooks/Books
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.
FAIL is not a helpful error message, need to log some more useful info.
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.
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.
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!
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.