]> git.lyx.org Git - lyx.git/blobdiff - development/HTML/HTML.notes
Update notes.
[lyx.git] / development / HTML / HTML.notes
index 8b7f9e116e917b4c884dbdf50e9468f17fc8afc5..da9993720e15e573d2bbf11031567381eddaf068 100644 (file)
@@ -1,81 +1,84 @@
-The main output routines now more or less work.
+TODO:
+1. The counter patch, and better output for InsetRef.
+2. Better output for citations, meaning better labels. Numerical, as said below,
+   should be easy, and author-year oughtn't to be THAT hard. But it'll need a 
+        bit of work.
+3. CSS needs work in several places, mostly floats. Maybe check elyxer on that.
+4. MathML
 
 
-Known issues:
-- InsetLine normally appears in a standard environment, which puts <hr /> inside
-       <p>, in violation of the DTD. I guess we could close the paragraph and then do
-       the <hr />, but isn't there a better solution? There's actually a LyX bug here, 
-       I think, since a line surely ought not appear in a normal paragraph?
-- The code that manages the nesting of tags is pretty primitive. It needs a lot
-       of work.
-
-These insets are basically done, though there are probably issues here and there,
-       and there are even some FIXMEs:
-       Bibitem, Branch, Collapsable, Footnote, Hyperlink, Label, Line, Note, 
-       Newline, Newpage, Quotes, Space, SpecialChar
-
-These insets do nothing for XHTML:
-       ERT, OptArg, Phantom
 
 These insets work but still need work:
 
 These insets work but still need work:
-       InsetBibtex: There are a few issues here. One is that the output is not very
-               nice. This will be solved, though, by a patch of mine I seem to have forgotten
-               to finish. To get output that accorded with the BibTeX style, of course, we'd 
-               have to parse the bbl file. I don't know if that's worth it.
-               Another issue concerns cross-references. At the moment, we simply use the
-               xref information for every entry, rather than listing the xref separately and
-               then referencing it. That should not be terribly hard, but it would take a bit
-               of work.
-       InsetBox: We need a Length::asHTML() method and the like, but it basically works.
-               though the CSS isn't there yet.
-       InsetCitation: This has two limitations as of 11 VI 2009. The first is that we
+       InsetBibtex: There are a few issues here. 
+               - One is that the output is not very nice. This will be solved, though, by 
+                       a patch of mine I seem to have forgotten to finish. 
+               - Another issue concerns cross-references. At the moment, we simply use the
+                       xref information for every entry, rather than listing the xref separately and
+                       then referencing it. That should not be terribly hard, but it would take a bit
+                       of work.
+       InsetBox: The CSS isn't there yet.
+       InsetCitation: This has two limitations as of 20 XI 2009. The first is that we
                ignore the citation style and output square brackets, no matter what. The
                ignore the citation style and output square brackets, no matter what. The
-               second is that, with BibTeX, we simply use the BibTeX key as the citation
-               string, thus ignoring numerical, author-year, etc. It will not be too hard
-               to make numerical work. To do this, we need to collect information on the
-               used citations, alphabetize them, and then assign numerical labels via the
-               BibTeXInfo::label() method. A similar strategy will work for author-year and
-               the like, but calculating labels will be more complex---unless we just parse
-               the bbl file, which of course is the only fully general solution.
+               second is that we only do numerical citations. It will not be terribly hard 
+               to do author-year citations, but the complexLabel() routine in InsetCitation
+               will need adapting before that is possible.
+       InsetFlex: I think this one is OK, but it needs some testing.
+       InsetFloat: This seems to work OK, but it will need testing and tweaking. There is
+               also no CSS yet for these.
+       InsetFloatList: Seems to work well, but may need testing.
+       InsetGraphics: This works in a pretty primitive way, in that it outputs the graphic
+         and appropriate img tag. But we don't yet do any sort of scaling, rotating, and
+               so forth. That won't be hard, since we can just call ImageMagick to do this for 
+               us, but appropriate routines will need to be written.
+       InsetRef: At present, we just use the label name as associated text, and put it 
+               into square brackets. It'd be nice to be able to do more, but for that we'd need to
+               associate counters with the labels, and we don't have that yet.
+       InsetTabular: Works reasonably well, but we don't do anything with any of the 
+               arguments provided for longtable. There are probably other limitations, too,
+               since I'm very much not an expert with tables.
 
 
-These insets do not work but should be completely straightforward:
-       Caption, Flex (uses collapsable)
 
 
+Math
+  We have a fair bit of math now working via MathML output, but there are still some 
+  isues, and not all the insets work. Here are the ones I know still need work:
+       - Array: Should be able to use alignment information via appropriate attributes, for
+               mtable, mrow, and mtd.
+       - Box: There is a general issue here with text mode nesting. See the FIXME attached
+               to the SetMode class.
+       - Lefteqn: For this, and numbering in general, probably need mlabeledtr, which may
+               mean we always need to output <mtable>.
+       - Par?
+       - Phantom: There is some support for this in MathML....
+       - Ref: Needs to be deferred.
+       - Size: Unclear if we want to do anything here, though we could. See
+               lib/symbols for the commands supported, of course.
+       - Space: Needs checking.
+       - SpecialChar: Needs checking.
+       - Split: There are some alignment issues here, but it basically works.
+       - Substack: This is a stack of however many cells, all in a smaller style.
+               Probably do something with <mover>, again.
+       - Tabular: This is more or less a text-like table in math. Probably output it
+               as a table, but set the font.
 
 
-May need to make use here of TocWidget::itemInset, which should then be moved
-to TocBackend.
+Other math notes:
+       - Hull:
+               -       Need to handle the equation hull type by outputting a counter. But that will 
+                       have to wait for the counter patch. The counter probably goes with mlabeledtr, 
+                       which may mean we always need to output <mtable>.
+               - Similar issues about eqnarray.
+               - It's not clear if we need to do much about the other hull types.
+       - XYMatrix: So far as I can tell, using this in LyX effectively involves using a
+               lot of ERT, within the matrix, to get the arrow effects. At present, it just prints
+               as an InsetMathGrid, from which it inherits, and so as a simple table. I don't know
+               how much more we can do.
 
 
-These do not yet work and need some attention:
-       InsetCommand: By default does nothing. That may be right?
-       InsetExternal: I don't understand these so am not sure what to do.
-       InsetFloat: This will need some work, again because I do not really understand
-               what these are meant to do. Presumably, we'll just use a div or something, but
-               it's not clear what subfloat means, etc.
-       InsetGraphics: This should be fairly straightforward, but I'll need to learn a bit
-               about export formats, etc, to get it completely right. We'll also want to make
-               some use of the params, eg, on width and height. I guess there is also some
-               issue about converting the graphics formats?
-       InsetInclude: I think we just want to include it, straightforwardly. Probably will
-               base this more on the latex() routine, then. Another possibility, maybe with a
-               flag of some sort, would be to do it as a separate file, to which we link.
+
+These insets do not work and are not yet scheduled to work:
+       InsetExternal: It may be that this won't be too hard, but I don't understand 
+               these so am not sure what to do. For now, it is disabled.
        InsetIndex and InsetPrintIndex: An "advanced" case. What really would be cool 
                would be to collect all of these and then write the index as a series of links 
                back to the occurrences. But not now.
        InsetIndex and InsetPrintIndex: An "advanced" case. What really would be cool 
                would be to collect all of these and then write the index as a series of links 
                back to the occurrences. But not now.
-       InsetInfo: Probably skip it.
-       InsetListings: Probably just output it as <pre>.
-       InsetMarginal: Fine, but will need CSS.
        InsetNomencl and InsetPrintNomencl: Also "advanced".
        InsetNomencl and InsetPrintNomencl: Also "advanced".
-       InsetRef: Presumably, this is an internal link. But what should the text be, and how
-               should we get it? Probably some validation thing again, where labels tell us where 
-               they are. Alternatively, we could parse the aux file.
-       InsetTabular: This shouldn't be too hard, but will need doing.
-       InsetTOC: Here again, validation might do the trick, but I'm not sure. Or perhaps some
-               kind of post-processing? Another option, maybe the best option, would be just to use
-               the information we already have in the TOC.
-       InsetVSpace: This will be easy, once we have the Length::asHTML() method.
-       InsetWrap: This should be simple enough, probably a div and some CSS, but I'm not sure
-               precisely what this is supposed to do.
 
 
-MATH
-       Regarding math, the view seems to be that we should in the first instance just use what
-       we get from instant preview and copy those over to the output directory, and then try
-       to make MathML work.
+May need to make use here of TocWidget::itemInset, which should then be moved
+to TocBackend.