Re: [Texmacs-dev] General efficiency of TeXmacs

[Joris van der Hoeven]

On Mon, Jun 15, 2009 at 11:52:04AM +0200, Gubinelli Massimiliano wrote:
> >I don't fully understand. You're saying all the full-windows redraws  
> >are not an error? I assume only only having the one partial redraw  
> >after a key press is the correct behavior.
> 
> I'm not sure: I think the typesetting engine send a series of  
> redrawing messages: starting from a local one and going towards a  
> global redrawing, but I'm not really sure. It should be checked on the  
> X11 backend.

On the X11 back-end, you should only see partial redraws.
However, there maybe total redraws in the case when the height
of a line changed. This typically happens quite often when typing maths.

> >Reencoding fonts iself is easy. With FontForge I was able to  
> >reencode and merge the GPL'd Base 35 fonts (Times, Helvetica,  
> >Palatino, etc), Liberation, and DejaVu into TeXmacs' format.
> 
> apriori reencoding of the fonts could be a solution. However it would  
> be nice to be able to use generic fonts (for example all the fonts  
> already installed on the platform). Moreover encoding could be found  
> out using freetype.
> 
> Another probles is that there are few (none?) OpenType fonts with  
> proper support of mathematics. How do you handle mathematical glyphs  
> in your home-brewed fonts?

That is actually a major point: the only decent math font I know of
is indeed the one from TeX; the alternative symbol font is not nice,
even though it is widely used nowadays. And once you choose another
text font, such as times, the math font should mix well.

> >TeXmacs uses FreeFont internally now to rasterize glyphs to bitmaps,  
> >so OpenType fonts will not pose a problem for the X11 port. But we  
> >will also need to have the fonts in pfa or type42 format so they can  
> >be embeded in postscript.
> >
> >The only inefficiency with native Qt font rendering is that Qt has  
> >to do complicated script anlasis, shaping, deal with kashidas, etc  
> >for every character draw operation. But I don't think this is a big  
> >deal.
> 
> I do not like very much the Qt API for fonts. In my opinion it is too  
> much high level for the needs of TeXmacs. this is why I wrote a cairo  
> renderer.

We probably should have our own abstract API for the moment,
so that we can experiment with several back-ends.

> I'm sending you a patch which reorganize the way fonts talks to  
> renderer. Its aim is to have an higher lever API so that native  
> rendering of fonts can be properly implemented.
> Virtual fonts still handle rendering via bitmaps (even if we should  
> think to a cleaner solution via higher level commands sent to the  
> renderer, other possibility: OpenType "glyplets").
> 
> I'm really interested in the problem of native font rendering.
> We should try to go on in this direction.

I confirm that I also want to go into this direction,
but there are many issues which have to be dealt with.
I attached a previous mail to Max.

Also, completing the Qt port should be our first priority.
When adding too much instability, we will loose control.

Best wishes, Joris

----------------------------------------------------------

> I was after native Type1 fonts on Mac for a long time. Not it seems
> to work but for the moment it is just an hack. I would need a 
> different design for the font subsystem. 
> A font can be rendered via different mechanisms according to the 
> rederer to which it is directed. For example the printer renderer does  
> not render the bitmaps but try to find the corresponding pfb file and 
> include it in the PS output. Similarly on the Mac the TeX fonts and  
> any kind of standard fonts like TrueType can be rendered via standard 
> system call (which is faster and usually of better quality than  
> freetype). So we would need a way that the rendered can influence the 
> glyph drawing process by telling the font that better altenatives are  
> available.  
>  
> Do you have any ideas about the correct way to do this.  
  
Yes, I have several ideas on how to achieve this.  
A clean solution would be  
  
 1) A systematic use of Unicode, with a plane for TeXmacs extensions. 
  
 2) Replace the current rendering routine for glyphs in renderer  
    by one which takes the font and a unicode string as arguments. 
  
 3) Provide suitable methods in the abstract font class in order to  
    retrieve glyphs and relative positions for backward compatability. 
  
However, point 1 of this clean solution also requires to adapt or  
get rid of some excentricities of the TeXmacs font system: 
  
 a) Virtual fonts: the implementation of virtual fonts has to be adapted
    so that it is no longer based on the computation of glyphs,  
    but rather recursively on the main rendering routine for fonts,  
    possibly with some extensions for flipping, clipping, etc. 
  
 b) Extensible characters: we have to get rid of the current way to  
    deal with big delimiters and take a week or so to write routines  
    for the *beautiful* rendering of all types of big delimiters  
    (and maybe more, such as arrows) based on graphics primitives, 
    rather than fonts, with parameters for thickness, etc. 
  
If you want to invest in this, you will probably need quite a lot of time. 
I am willing to help, but we really need something clean here, not a hack...