Andrea Gavana wrote:
- A wxWidget, that renders a DVI file !
Pretty much this.
I have never used DVI files ;-), but I can investigate some more
It's a actually a pretty simple format, though it is binary. DVI is the the "Device Independent" output from TeX. It specifies where on the page each letter should go. Kind of like PS and PDF, I suppose, but it pre-dates postscript.
I'd love to see a small TeX engine that could be included with wxPython,
without the overhead of a an entire TeX distribution. That would be
challenging, I now, but I do think there are folks working on a
embeddable TeX for other purposes, that maybe could be put to use.Mhm... it seems to me that everything that is *now* a good text editor for
wxPython is actually written in C++ and wrapped in wxPython.
A TeX engine is NOT a text editor, at all. TeX is a typesetting engine. It figures out where on the page each individual charactor should go, and it does it VERY well. One of the reasons it does so well is that it examines essentially the whole document at once, and does a balancing act to get the whole layout looking good. One reason WYSIWYG word processors do a much worse job is that they need to typeset on the fly, as you type, so it can't take into account how other paragraphs asn other pages effect the layout. Computers are pretty fast now, so I suppose one could at least typeset an entire paragraph every time someone types a letter, but I suspect it would still feel unresponsive. It would also probably feel strange, and the word you're typing could move from one line to the next and back again as you type.
There is the option of semi wysiwyg, where the gist of the layout is the same as you type, but the final layout is computed afterward.
Given all that, what I have been envisioning is really a one way street, more like wxHTML, but with more control and better quality layout.
Scintilla. It is nice, compact, fast... but it is not written in Python.
Will the Python function calls overhead kill the performance of such a
widget? (Maybe it's a stupid question).
I doubt you could get a really responsive version written in pure python, but certainly more of it could be.
If someone has some idea on how *to
start* implementing such widget, I will be happy...
I see three issues:
1) A DVI driver for wxDC: It would take DVI input, and render it in a wxDC. this wouldn't really be that hard, once you figured out the DVI format.
2) An embeddable TeX engine: I think there are other projects working on this, This issue is that TeX is really a full language designed for typesetting, and id usually used as a command line tool. To make it really useful, it comes as a "distribution", with a LOT of macro packages, fonts, etc, etc. All this stuff ahs to be all installed in a way that TeX can find what it needs when running. My idea is NOT to embed a complete TeX distribution, but to strip it down to the baqsic function -- jsut the typesetting
Which brings us to:
3) A font system: natively Tex needs "*.tfm" (TeX font metric) files, which specify how the letters of a font all fit together, so that the layout can be determined. The fonts themselves are traditionally rendered by an associated program called MetaFont, which renders bitmap fints at a specified resolution, from a vector description. This is all analogous ot PS Type one fonts and True type fonts, but it pre-dates both of those. I'm not sure of the details, but TeX is now often used with Type1 and Truetype fonts, but I think it stil requires that the *.tfm files be generated from thos fonts. You can see why this gets complicated!
jmf wrote:
I do not want to refrain you working for wxPython. If you have some
spare time, I *warmly* recommend, you have a look at (La)TeX.
I second that. Every Scientist and engineer should know about it. (so should anyone creating structured documents, but it really shines when there is math involved)
http://toolscenter.org/front_content.php
aka TeXnicCenter as a front end or user interface.
I hadn't see that. It looks very nice,.. Too basd it's Windows only...if only they had used wx!
A few months ago, I started to develop a clone of
TeXnicCenter in Python/wxPython. I gave up after a week. From a programming point of view, it is not terribly difficult, it is a lot
of work.
I imagine it was hard to justify, given that you have a working product on your platform of choice.
Hey, there's pdfTeX out for some years now! There's really *no* reason to use DVI anymore!
Well, except that I think a PDF interpreter is a much bigger project than a DVI interpreter. Although if you only support pdfTeX output, maybe not. By the way does pdfTeX produce pdf directly? or is a DVI driver?
Actually, I imagine an html to TeX converter.
That's rather easy.
You can even feed XML directly to some TeX engines (e.g. ConTeXt, see http://wiki.contextgarden.net)
Very cool, but I was imaging one writen on Python, or easily embedded in Python, I'd have to dig more into that.
Anyone interested could perhaps help with the "TeX as C libs" at http://www.metatex.org/
That's exactly what I was thinking about. The web page hasn't changed since 15 september 2004 however.
or ExTeX (enhanced merger of NTS, pdfeTeX, Omega in Java) http://www.extex.org/index.html (task: port that to Python! ;-))
I can't seem to get to that web page right now.
Thanks for the pointers.
jmf wrote:
I do not agree. DVI <-> METAFONT. pdf/ps <-> TypeN fonts. In short, the
glyphs in METAFONT are different for every available font size, this is not the case for Type1 fonts.
One more reason TeX does such a good job. However, type1 and TrueType are kind of ubiquitous now.
Paul McNett wrote:
Well, eventually, I hope there will be a wxPdfWindow control.
yes, that would be nice, but a long way off, I'm afraid. I'm still hoping for a way to write PDFs, which is much easier. There's good progress on that one though, at least with C++ wx.
Well, with a combination of knowing what printer you want to send to, and the PDF, you can do that, no?
Can you? programatically, reliable, on all platforms? Do tell!
Right, for now we are just using whatever external viewer the user wants to use.
Which I'm sure works, but it is sub-optimum.
This would be a great thing. I originally looked at wxPostscriptDC, but abandoned that because I was running into walls (can't remember what the walls were, though).
I wonder, it's worked for me, but *nix is the only platform that PS is a natural for.
David Woods wrote:
I've had a significant number of users
complain about this approach because they want to be able to capture
portions of the report text for inclusion in articles, reports they're
writing, etc.In my opinion, any solution you consider for a reporting framework should
allow printing, saving of reports (perhaps in a couple of formats), and the
cut-and-paste capture of report text for re-purposing.
That's a good point, and an additional challenge. Darn!
I totally agree. A PDF would give you all of this, no?
Um, no. The problem is that PDF was designed to a be a one-way street, to describe how a document looks, but not what it means. A simple paragraph of text is fine, but when text gets laid out in columns, or tables, or whatever, the relationship between the different chunks of text is gone.
David Woods wrote:
But will the wx.PdfDC support all of this? I certainly hope so.
Well, No. A wx.PdfDC would only write PDF. If you want the whole cut & paste thing, you need a full rich-display widget. Much like wxHTML, in fact. Maybe improving that is really the best way to go!
As I think about it, it may be that what's being talked about in another thread--a report tool borrowing from PySketch does make sense: then each block of "stuff" in the report is a object, and you should be able to support cut & paste, etc. from any given object. Some example objects;
A paragraph of text
A table
An image
others?
And if it uses wx.DC, then you get print preview, printing, PS, and hopefully PDF output soon. By the way, my FloatCanvas could provide some inspiration too. The text support is mimimal at the moment, but some of the framework might make sense to use. Make sure to ask me for the latest version: I've added some text layout, primitive though it is.
Conclusion to all of this: There is work to be done! My personal interest partially lies in really wanting the nice typesetting that TeX provides. Whether you use a DC, PDF, PS, or whatever, you still need to figure out how to lay out the text. Laying out even a simple paragraph is not trivial, and most software does it poorly.
-Chris
···
--
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception