Talk:Add Math Support

From Scribus Wiki
Jump to navigation Jump to search


Just one more idea: take a look at MathML. In contrast to LateX/TeX, MathML is an XML standard which would make it more compatible to the Scribus file format.

There are some C++ - libs which can be a good starting point:

As stated in one of the feature request linked from the proposal, MathML is good for software, but it is hard to write for humans. OTOH the output of your first link looks quite good and it would remove the dependency on external software. So here's a list of pros and cons I can think of:


  • No external dependency
  • Better integration with XML


  • Hard to edit by humans
  • Many people are familiar with latex
  • With LyX a pretty good editor for latex exists
  • mml-widget has font problems *)
  • Porting form GTK might be required

*) (From the mml-widget webpage) Warning: you may notice some differences between the rendering of GtkMathView and the screenshots above. This is primarily due to the actual fonts installed on your system. Note also that some fonts are buggy, that is they have wrong/strange metrics for some symbols. In particular, the symbol font (75dpi) usually shipped with Unix/Linux has a buggy vertical bar for the integral sign, so that large integrals have the middle part misaligned.

Additional Links

Some More Thoughts

One more pro of MathML:

1.) It's no problem to convert them into SVG. Scribus can handle SVG already properly, so that the graphik rendering wouldn't be a big task.

2.) I agree with you that MathML isn't nice to handle manualy. But there are some editors which are using a simple syntax for equations, for example OpenOffice. Exporting them into MathML works fine.

Perhaps it could work this way:

a) Add an special equation-editor to Scribus. It uses a simple, manualy manageable syntax.

b) Than, export it into MathML. Store the MathML-Code in the Scribus file.

c) If it comes to rendering, convert the MathML to SVG and let Scribus do the rest.

(Take a look at GtkMathViewer (, it seems so that the AbiWord-people used it for adding mathematical functionality to AbiWord)

Btw., discussions within a Wiki are a terrible thing .... ;-(

Other thoughts

Embedding other external tools

In the original discussion on adding Latex frames in the bugtracker (, the idea came up of embedding output from other programs in frames as well, like a plotting tool. It would be great if you design the scheme for storing Latex source, automatically calling Latex and embedding the output to be general enough that other things besides Latex could be supported in scribus frames in the future.

I'd love to be able to type in an equation and have not only the equation itself, but also its graph, automatically update when I edit the source. :) --Mkoren

That should be possible. Path to LaTeX has to be configurable anyways, so it's no big deal to let the user choose different programms to. The only requirement is that the programm outputs a format that is supported by image-frames (pdf, ps, png, etc.) --Herm 16:20, 7 April 2007 (CEST)
Just my two cents: Especially supporting XSL FO would be a great extension for Scribus. With an XSL FO processor like the Apache FOP, great looking tables are possible :-) --TomZ

On other TeX flavors and MathML

Someone posted a comment on the main scribus summer of code ideas page, under the Latex frames support section, that's rather interesting. Evidently there are some other TeX distributions besides Latex which have improved font support, and/or can actually render MathML themselves, and in one case can still render Latex as well.

Maybe looking into these could reduce the work you have to do to integrate TeX with Scribus styling, and even give the people that prefer MathML a route to go as well without any extra effort on your part. --Mkoren

As users can select any program they want (see above) they can use any TeX flavor they like. Perhaps I even can add an ConTeXt-Font selector if time permits. However I think LaTeX should stay the default: Latex is widespread (users don't have to install a new programm) and the editor I intend to use (LyX) is for latex. I have to check if context is 100% compatible to latex. So my solution would be: Latex default, ConTeXt user-selectable. What do you think about this? --Herm 16:20, 7 April 2007 (CEST)

New Idea

I've thought about this ConTeXt, graphs, MathML, etc stuff a bit and had a new idea:

  • Presets for different programms

One could add a new programm by specifying the following items:

  • Name of preset
  • Path to executable
  • Path to editor
  • Uses templates?
  • Input-/Outputfilename format (so scribus knows that tmpXXXX.tex will be processed to tmpXXXX.pdf)

When you add a TeX-Frame one can select which format you want to process and scribus automagically selects the right programms to process or edit the input.

A simple UI for adding new presets should be only little work.

Example preset


Example template

The syntax is only a example and not fixed yet.

<param value="font" desc="Font" type="list">
    <option value="arial" desc="Arial (Sans-Serif)" />
    <option value="cm" desc="Computer Modern (Serif)" />
<param value="color" desc="Color" type="color" /> 
<param value="background" desc="backgroundcolor" type="color" /> 
<param value="size" desc="Fontsize" type="number />

This sounds great! I think this would be a good way to do it and would open up a lot of useful possibilities. This will definitely be a good addition to Scribus.
I thought of one thing to keep in mind regarding security--we can't exactly allow a document to be automatically calling any program it likes in the background. :) Scribus has no way to know that it will really just return an image. This is the same sort of thing discussed on the scripter project page. It's a pity, because I was just envisioning some great shell commands to do fun things. :)
But I think maybe a solution could be to let a user define a list of allowed programs in preferences, and then ask if a document tries to call anything else. I think it would be worth adding this extra step to get the benefit of calling different programs, most of which would probably be in your own documents so you could enable the needed programs once, and write a specialized script if you need to do anything fancy.
Oh, one more thing though--it would be desirable to be able to use custom templates on a per-frame or per-document basis, but that's another security consideration, because a program could be safe to use only with certain options or settings...this may require a bit more thought. Still, I think this is a very good direction. --Mkoren 04:57, 13 April 2007 (CEST)