1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106
|
* Support other formats than just LaTeX
plain TeX users and ConTeXt users should not have to feel left
out. While ConTeXt is not supported yet by released versions of
AUCTeX, at least supporting plain would help people, and be a start
for ConTeXt as well. There are plain-based formats like MusiXTeX
that could benefit a lot from preview-latex. The main part of the
difficulties here is to adapt `preview.dtx' to produce stuff not
requiring LaTeX.
* Support nested snippets
Currently you can't have both a footnote (which gets displayed as
just its footnote number) and math inside of a footnote rendered
as an image: such nesting might be achieved by rerunning
preview-latex on the footnote contents when one opens the footnote
for editing.
* Support other text properties than just images
Macros like `\textit' can be rendered as images, but the resulting
humungous blob is not suitable for editing, in particular since the
line filling from LaTeX does not coincide with that of Emacs. It
would be much more useful if text properties just switched the
relevant font to italics rather than replacing the whole text with
an image. It would also make editing quite easier. Then there
are things like footnotes that are currently just replaced by
their footnote number. While editing is not a concern here (the
number is not in the original text, anyway), it would save a lot
of conversion time if no images were generated, but Emacs just
displayed a properly fontified version of the footnote number.
Also, this might make preview-latex useful even on text terminals.
* Find a way to facilitate Source Specials
Probably in connection with adding appropriate support to
`dvipng', it would be nice if clicking on an image from a larger
piece of source code would place the cursor at the respective
source code location.
* Web page work
Currently, preview-latex's web page is not structured at all.
Better navigation would be desirable, as well as separate News and
Errata eye catchers.
* Manual improvements
- Pepper the manual with screen shots and graphics
This will be of interest for the HTML and TeX renditions of
the texinfo manual. Since Texinfo now supports images as
well, this could well be nice to have.
- Fix duplicates
Various stuff appears several times.
* Implement rendering pipelines for Emacs
The current `gs.el' interface is fundamentally flawed, not only
because of a broken implementation. A general batchable and
daemonizable rendering infrastructure that can work on all kinds of
preview images for embedding into buffers is warranted. The
current implementation has a rather adhoc flavor and is not easily
extended. It will not work outside of AUCTeX, either.
* Integrate into RefTeX
When referencing to equations and the like, the preview-images of
the source rather than plain text should be displayed. If the
preview in question covers labels, those should appear in the
bubble help and/or a context menu. Apropos:
* Implement LaTeX error indicators
Previews on erroneous LaTeX passages might gain a red border or
similar.
* Pop up relevant online documentation for frequent errors
A lot of errors are of the "badly configured" variety. Perhaps the
relevant info pages should be delivered in addition to the error
message.
* Implement a table editing mode where every table cell gets output
as a separate preview. Alternatively, output the complete table
metrics in a way that lets people click on individual cells for
editing purposes.
* Benchmark and kill Emacs inefficiencies
Both the LaTeX run under Emacs control as well as actual image
insertion in Emacs could be faster. CVS Emacs has improved in that
respect, but it still is slower than desirable.
* Improve image support under Emacs
The general image and color handling in Emacs is inefficient and
partly defective. This is still the case in CVS. One option
would be to replace the whole color and image handling with GDK
routines when this library is available, since it has been
optimized for it.
|