On 12/08/2011 11:26 AM, Rob Oakes wrote: > Hi Guenter, > > On Dec 7, 2011, at 1:14 AM, Guenter Milde wrote: > >> IMV, we should make the placement of footnotes in HTML configurable. >> >> Sensible options include >> >> a) inline (as "tooltip" via CSS :mouseover:) >> b) in the footer for page-based output (e.g. print from HTML or ePub) >> c) endnotes (before/after other concluding sections and listings?) >> d) per chapter/section/subsection >> e) author-specified position via an inset > I'd really like this too, but I'm not sure what the best way to implement it > is. Putting HTML footnotes at the end (or collecting them as Richard as > suggested and I'm currently working on a patch for) is pretty straightforward > to code. (And I'm a pretty modest C++ coder.) > I think (a), (c), (d), and (e) all work via the same inset. If it's not there, you default to (a). Where it is (and how often it appears) tells you which of the others you are doing. As for (b), I am not sure how to handle it. But I don't like having document options for such specific things. This leads to having way too many document options.
> The reason I like is that I can easily customize and control the output using > the CSS styles in the layouts. Yesterday, I spent all day at a publishing > conference talking to in-house programmers/designers and they identified a > couple of things they would want to see: > > 1.) the XHTML should be as clean as possible, following XHTML5 and ePub3 > conventions > 2.) CSS styling should be as transparent as possible, with intelligent > defaults > 3.) It's very important that it be easy to customize > > LyX already provides for two and three. With some tweaking, the XHTML that > comes out can be very clean and the LyXHTML can be customized via the > document or Internal layout file. > Let me know where things need improving re (1). > I can foresee that a designer might want to tweak the CSS regardless of which > export option they are using, but what is the best way to do this? In the > layout, we can only specify one category of CSS that will get applied, > regardless of which export option is used. It seems like the other approaches > would require hard coding it, which seems like a less effective approach. > Presumably, one could use different modules for different output options. This would require adding and removing them, but I can't see having document preferences for such specific things. Now that we have the option (in trunk) to write the CSS to a file, this would make it fairly easy to have different sorts of CSS for different purposes. The other thing to say, of course, is that footnotes appearing as endnotes should use a different CSS class than footnotes appearing inline. Then one just includes CSS for both, one of which does nothing. > Anyway ... I'll continue work on collecting footnotes and send a patch a > little bit later today. > I've been thinking about this as well and will be happy to work with whatever you produce. I have also been thinking that the inset for printing endnotes might well be useful for LaTeX, as a replacement of sorts for the Foot To End module. If it's there, we write footnotes as endnotes. > PS, on another note, I'm pretty excited about the export of splitting the > HTML file at the chapter or section level. Is there anything that I can do to > help facilitate it? > I've been thinking about this and actually think it isn't that hard to do. I'll get to it once the semester is over. > There are six big challenges I see to getting really excellent HTML/eBook > output from LyX : > > 1.) Clean up the HTML tags to follow HTML5 conventions (easy, configurable > through layouts, in progress) > For 2.1, perhaps we should be thinking in terms of HTML5 rather than XHTML altogether? > 2.) Export CSS styles as a separate file (done) > 3.) Allow for more flexible handling of footnotes (in progress, moderately > difficult) > 4.) Split large HTML documents into more manageable chunks, perhaps at the > chapter level (unknown) > Will be done over the holidays. > 5.) Allow for images, equations and other assets to be moved to a logical > subfolder hierarchy (unknown) > The only reason I didn't do this originally was because I was lazy. It should be hard, I wouldn't think. The main question is what counts as a "logical subfolder hierarchy". > 6.) Create a specialized inset which is able to insert audio and video using > the audio/video tags (unknown) > This ought to be do-able via InsetExternal, though at the moment there is no HTML support for that inset. But this was just because I didn't see what it would be good for. I guess we would need to extend the template description language to include some way of specifying the HTML tags used with this type of file. One could more generally allow for conversion, though maybe we do not need to do that at the beginning. I'd suggest filing a set of bug reports for these, so they are in one place. Perhaps start with a meta-bug concerning HTML and ePub stuff, and then add references to the other bugs to it. Richard
