Not sure I follow. If we use tags, then CSS can color this for XHTML, and the XSLT can transform it into a color tag for LaTeX. This would leave out RTF, however.
If you use the approach, then you get color in XHTML, and I believe RTF, though I have not tested it. You could easily add a bit to the scrivener2latex XSLT file to match a span tag with color assignment, and do whatever you like with it (add color, make it to a marginpar comment, whatever.)
So, for flexibility, it sounds as though the span approach might be the best. The span could have a class of annotation to provide some semantic meaning, and make XSLT matching more reliable.
Hmm. In my testing (which I just tried again to confirm), the styled method does in fact carry over to the RTF. “Out of the box,” this method would provide colouring for RTF and XHTML. If Keith decides to leave the “third XSLT” option out of the main distribution, that is, while leaving it relatively simple to add our own XSLT additions as individual users.
I thought of using a regular span tag, but honestly converting:
<span style="color:rgb(0.7, 0.0, 0.2)">This is a comment</span>
to:
\color[rgb]{0.7, 0.0, 0.2}{This is a comment}
is a bit over my head. No doubt, that would be the best solution, though, if it is easy to do, since it would retain user’s colour choices – and keeps the XHTML compliant with spec.
I would not do it that way - LaTeX will not pass unscathed through MMD… I would stick with the approach I described above.
I believe that RTF is an acceptable format only insofar that Word’s .doc format is worse. An RTF file viewed in TextEdit, Pages, Safari, Word will not look the same. I agree that the basic content is there, and that it is more cross-platform that some other formats. But it bothers me that the appearance varies SO much.
With modern computers that can do so many amazing things, you would think they could make a piece of text look similar across machines (which is why postscript and PDF was invented).
My choice of the word “crappy” was intentionally a bit over the top, but it’s merely to point out that we seem to be accepting a lack of consistency in the format that we don’t tolerate elsewhere in modern computing (“well, when excel does the math on my machine you owe me $100. On your machine I owe you $92. Close enough…”)
But short of PDF with embedded fonts, I agree that it is one of the better alternatives out there. And far and away, it SHOULD be the format for something like Scrivener for those who aren’t as picky about the formatting details.
LaTeX is certainly not for everybody (I very rarely write a LaTeX command by hand.) But one of my hopes is that something like MMD (not necessarily MMD itself), that can produce consistent PDF output with a simpler markup, could have a user share and bring high quality documents to more people.
This is easily doable. I am away from my home machine to test the XSLT and play around, but I could easily code up an addition to the XSLT to handle this.
I will throw in the warning alluded to above - when at all possible, I recommend using the “semantic” alternative () rather than hard-coded formatting (). But either way is possible and can coded to a Scrivener specific XSLT.
Well, this is odd. Fletcher said colour drops in RTF too, but I am sitting here looking at an RTF with a red annotation that has been underlined, precisely like the XHTML file looks.
I’m running OS 10.4.8, by the way, and unfortunately textutil is not providing a version number.
Well, like I said in my last post, I’m kind of hoping that someone will send me a “third XSLT” option (maybe even with some updated shell scripts) that I can incorporate right away (hint, hint).
Fletcher:
I agree with you about RTF. My main annoyance, though, is that it is a well-documented format and yet so many implementations leave so much out. I believe Apple are partly to blame here. RTF footnotes, comments and images are not so difficult to incorporate - if I can add them to the RTF exporter, then they can’t be. And yet, Apple have so far left these out. By far the most neglectful part here is images - on a Mac, if you want an image in an RTF file, you have to save as RTFD, which is nothing more than a folder containing the RTF file and the image. This seems very silly when RTF is more than capable of handling images. I understand that they wanted to extend RTF to incorporate movies and PDF files etc, but they could have done this as well as better supporting the RTF format. So, in essence, I believe it is not so much a problem with the format, per se, as with the fact that so many applications have not embraced everything the format has to offer.
Ordinarily I completely agree, inline styling is next to sin The issue that we have here is that in Scrivener a user can select from the million or so possible colours available to the Mac’s colour picker. In practice, they might have any number of differently coloured annotations in a file. This would mean Keith would have to dynamically generate a CSS class for each colour, and assign it to the span. Under “lab” conditions this might not be too bad, but I can easily see less picky users grabbing a “close match” colour every single time – and there is colour blindness to consider, too – leading to potentially thousands of classes (since a full export is just that – an entire book). A real mess.
Given this direction, I think it would be best if you take the XSLT from here. I’m really only versed enough to add simple tags, at this point.
No problem. I might have taken your speculation on it dropping to be some knowledge I was lacking. The approach is simple:
<style type="text/css" media="all">
annotation { color: rgb(.7, 0, 0); text-decoration: underline; }
</style>
...
<p>This is a paragraph in my story, blah blah <annotation>This paragraph should really have more to do with the story.</annotation> blah and so forth.</p>
Despite (apparently) being an abuse of the formal specifications, this works everywhere, including the textutil installation I am using. Text comes up red and underlined in both browsers and TextEdit.
Hopefully that makes more sense. But this is all moot since we are going with spans.
I expect to have time to work on whatever would be helpful Sunday/Monday. Perhaps I overlooked a URL, or can’t find the feature - the version of Scrivener I have doesn’t have any hooks into MultiMarkdown.
What exactly do you need re: MMD? What should the script expect as input and provide as output? Just a shell script stringing together the proper pipes? Once there is a definite output format, I can also easily provide a scrivener specific XSLT (and include the latest, greatest MMD 2.0.a1 XSLT and perl script).
I jumped into this discussion sort of late, and have only played with Scrivener for about an hour, so I might be missing something obvious. (I can at least offer a “vague” understanding of the MultiMarkdown system though…
Okay, now I really am confused. Right now, I just need some way of getting these annotations into LaTeX, be that through very simple tags in the XSLT file or whatever. I know nothing about CSS etc, so a lot of this discussion is beyond me. I just need something solid to work with as I implement MMD tomorrow (the basics are already in Scrivener beta 3, now it’s time to get it working properly).
If the tag works with RTF and meets everyone’s needs, it will work with LaTeX, no problem. The only thing I need to look at is if you want to grab the user’s choice of color, it’s a touch trickier, but I believe it can be done.
I like the bit for readability, but I defer to what others expect to find more useful. I believe that either approach can be made to provide the proper formatting change (i.e. color) in XHTML, RTF, and LaTeX/PDF, and will happily provide whatever XSLT expertise I can to make it work. I suspect that the most important factor in this decision is what would work best with XHTML and the XHTML->RTF transform.
(aside - please challenge me on anything you disagree with. If there’s something that can be done better, or if I say something incorrect, I am happy to have it corrected. What I’ve enjoyed the most about developing open source software is the feedback cycle with users who help me fix bugs and add improvements. The same thing applies in these discussions - I like to hear what other people think, especially when they disagree with me!)
Keith wrote a test implementation of how Scrivener will utilise MMD. It is a simple app with all of the necessary scripts in its Bundle. I’m assuming that is the way things will be done, still. So K, correct me if I’m wrong. I mean, as far as the basic structure of the exporter works – not all of the finer details we are still hashing out.
edit Eh, and I forgot to mention that I am sending it to your point of contact (from the Wiki), Fletcher.
I like better, too. One thing that is nice about MMD’s XHTML output is how clean it is. Mucking that up with a lot of inline styling would be a shame.
With the test app I sent. There are some things being done behind the scenes. Basically the header is automatically generated, and the stylesheet (not customisable in the test app). So the actual Markdown that goes into the text entry field need not contain “Format: complete” and so on.
Yes, that test app does give a good example of how the basics will work. Obviously it only works for one document, and there remains such issues as how notes, synopses etc will appear when transformed into MMD, but that test app gives an idea of how the formatting will work (although it does not allow you to customise the font etc).
Well, technically, by the time it gets to the actual shell scripts, won’t it always be a single document? Isn’t Scrivener basically taking the whole draft, concatenating it, pre-processing title depth and so on, adding headers, and then sending it to the shell for MMD processing?
The CSS added would be in the header if all annotations are to have the same color (AmberV demonstrated this for the span approach). If each annotation can have a unique color, then the color would have to be included in each tag (e.g. ) I can say that if the color is included with each annotation (allowing different colors for different annotations), it would be easier to code the XSLT (e.g. I am 100% sure I can do that easily. I am 90% sure I can use a single color for all annotations with slightly more effort).
I can provide an XSLT to transform either of these approaches (99% sure) into LaTeX, but can’t do it until tomorrow (Sunday). This XSLT will be customized for Scrivener, and will allow drop-in replacement of the other parts whenever I update MultiMarkdown, so that you would not be responsible for keeping Scrivener up to date with MultiMarkdown releases.
I have not experimented with this enough to have a strong recommendation as to which of the above is better. In either case, if the decision made turns out to be the “wrong” one, it would be trivial to change after some beta testing.
I am more than happy to work on an XSLT solution for either approach that is agreed upon.
Many thanks, Fletcher - much appreciated. I would much rather go for the option of Scrivener defining the colour based on the choice the user made when defining the annotation in the first place.
<annotation style="color:rgb(0.7, 0.0, 0.2)">
would be very easy to add on export from Scrivener. Presumably this would work fine with RTF and XHTML export, too?
AmberV - yes, technically it would be one long document by the time it reached MMD.
Right, I’m off to relax and watch a film with a beer now!