I looked at page 647 of the manual, but it doesn’t say how to access the CSS pane. CSS in help don’t point to anything; the word “pane” leads to the Styles Panel.
CSS is found deep inside the Compile Format editor. When you open Compile, set your “Compile for” (at the very, very top) to epub. Then double click on one of the formats shown to edit it. You’ll see CSS as one of the options in the left sidebar. See section 24.7 in the manual for more information.
Hope this helps!
What specifically are you trying to do?
Styles are relevant both in the main Editor and in the Compile command. CSS is only relevant if you’re compiling to an HTML-based format.
Exactly. To e-pub, which is an html format. But since you asked:
Agency “C” has issued their laws in 35 separate pdf files. It is not possible to search all these at once (we’ll put aside a grep search of a separate directory). Wouldn’t it be nice to be able to search all the files at once? Download 35 pdf files. Convert each one to .docx using Adobe Acrobat, because Scrivener treats pdf’s as image files. Bulk import the 35 .docx files into a new Scrivener project. Compile to epub: the results aren’t bad, but the css file is more than 1000 lines long and there are places where text is squeezed or disfigured for no good reason. Trying to fix things in Calibre causes Calibre to hang. So the idea was to strip out the 1000 lines of complicated CSS and substitute a “basic” css stylesheet. That is why I needed access to the CSS styles pane.
So if you’ve got other ideas on how I can clean up the resulting e-pub file, by all means…
Well, you don’t need to Compile to ePub to search them. Once you’ve extracted the text, Scrivener, DevonThink, and numerous other applications should be able to search it just fine.
(Also, are you sure searchable text isn’t available online? At least in the US, many agencies publish both PDF files and searchable HTML versions.)
If you want an ePub for other reasons, the first thing I would do is normalize the text in Scrivener (or possibly in Word). It’s fairly likely that the conversion process left all sorts of weird formatting artifacts that are being faithfully passed through by the Compile command.
The CSS stylesheet is accessible via the CSS tab of the Compile Format editor. As Silverdragon said, see Section 24.7 in the manual for more information.
Sure, I could simply append all the pdf’s and end up with an 80mb or so file. Not very portable.
Extracting the text sounds like a good idea, but lists (can) have semantic meaning in law and plain text loses these.
I am sure that searchable text is not available globally. Not even in Arabic, the official language.
The pub that Scrivener produced was only 843 kb. Super-portable. Now if I could only fix the CSS…
You “extracted the text” in the sense that I mean when you converted it to .DOCX format, so I’m not sure what the issue is here. For the purposes of the original problem you are done.
If you want an ePub for other reasons, that’s fine, but it’s not necessary for the task you originally described.
? The .docx at times looks like crap when compiled, “there are places where text is squeezed or disfigured for no good reason.” I think there are more alternatives than an 80 mb appended pdf or a defective .docx. If I had the time, I could hand-code everything to LaTeX–I already tried compiling to .md–too many artifacts. Running headers are not part of the text. Unfortunately, they’re (sometimes) a defined terms so they can’t be jettisoned automatically. Finally, a single file is required for a global search. What form will that file take? I can’t distribute Scrivener project files-maybe someday that will be possible.
I guess the question here is – if you’re just compiling existing PDFs into a single searchable file, why are you even bringing Scrivener into the workflow at all? Convert them to .docx, put them in a single .docx file, distribute that file and be done.
Size of the file, mainly. Scrivener is pretty good for collecting, that is, making a binder consisting of disparate files and then being able to compile to various file formats. Depending on the size of some of the files, I might export to txt and then hand code a LaTeX file, giving an easily manipulable ToC and even an index–but at 800 or so pages, this one is just too big.
I realize it’s not a frequent use case. Now, if only Scrivener would treat pdf’s as documents and not images…
If the .DOCX formatting is bad, all formatting derived from it will be bad, too. It will probably be easier to fix it by either editing the .DOCX file or Scrivener’s RTF import of it than via the Compile command (to any format). That’s why I suggested using one of those tools – rather than the Compile command – to normalize the formatting. (Key word is normalize. I understand that plain text isn’t what you want.)
My own solution to this sort of problem is to use DevonThink. Handles enormous (millions of words) PDF collections without blinking, great search tools, supports a server option for sharing the archive.
Searchability of a PDF – with any tool – depends on whether the PDF comes with a text layer. If it doesn’t, then one has to be created, usually via OCR. That’s probably what Adobe is doing.