octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Update - LaTeX markup project


From: Patrick Noffke
Subject: Re: Update - LaTeX markup project
Date: Sat, 13 Jul 2013 10:10:12 -0500

Andrej,

On Thu, Jul 11, 2013 at 3:18 PM, Andrej Lojdl <address@hidden> wrote:
> So after quite time exploring how classes are related, I have small
> proposal. New abstract class should be made on top of ft-renderer and
> latex_renderer. It should be placed in txt-eng.h . It should have only two
> attributes pixels and bbox. And inside opengl_renderer , text_procesor
> should be define as our_abstract_class text_renderer . ft_renderer is
> already defined, so latex_renderer should be defined in separate file. I'm
> not sure in what moment we should pik one of these two renderers, based on
> interpreter value?
>

Basically, I think you are understanding the idea.  But there a few
details that I want to go over.

1. I gave you wrong information before (sorry about that).  I said
only glps_renderer was ever instantiated.  I used grep to try and find
it or opengl_renderer, and I don't know what I found, but that was
wrong.  In __init_fltk.cc, opengl_renderer is a private member
variable of OpenGL_fltk.  As Michael said, this is used for on-sreen
mode.  In OpenGL_fltk::draw, glps_renderer is instantiated as a local
variable if rendering in print mode (print_mode == true).

2. The text class has a 'renderer' member variable, which is currently
of type ft_render.  This only exists if HAVE_FREETYPE is #define'd.
And within graphics.cc, there is more code that is #define'd out if
HAVE_FREETYPE is not set.  As far as I can tell, you get no text if
HAVE_FREETYPE is not defined.  Question for the list -- would it make
sense to require both FLTK and FreeType in order to enable FLTK
rendering (and similarly, for QtHandles, we would require FreeType in
order to use Qt)?

3. The availablity of ft_render is decided at compile-time, whereas I
think it makes sense to decide latex_renderer availability at run-time
(i.e. if the required external programs are found in the path).  Then
when you set the 'interpreter' property, you will have to select
between ft_render or latex_renderer.  We could have the text class
contain (as a member variable) a pointer to the proposed base
text_renderer class, which defaults to an instance of ft_render (if
available).  But if both HAVE_FREETYPE is not defined and the latex
binaries are not available, this will be a nullptr.  Then we would
need to add nullptr checks around all uses of text_renderer within the
text class.  Perhaps this is the way to go.  Are there other
suggestions?

4. It appears the the font and the color affect the state of the
ft_render class (in text::properties::update_font).  Should these
attributes affect the latex rendering, or would we expect the font and
color to be specified in a latex string?

5. When is the interpreter property set?  Is it before setting other
properties like the font and color?  If not, I could see how the font
and color might not get propogated to ft_render (if latex was
previously set as the interpreter).  Maybe it makes sense to always
pass this down to the ft_render instance, if it exists, regardless of
what interpreter is set.  Or is there a way to ensure interpreter is
always set first?

Patrick


reply via email to

[Prev in Thread] Current Thread [Next in Thread]