View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000128 | Scribus | General | public | 2004-01-08 23:52 | 2008-01-30 12:48 |
| Reporter | cbradney | Assigned To | |||
| Priority | low | Severity | feature | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Platform | all | OS | all | OS Version | all |
| Product Version | 1.3.4cvs | ||||
| Fixed in Version | 1.3.5svn | ||||
| Summary | 0000128: TeX rendering engine library | ||||
| Description | Request for TeX rendering engine | ||||
| Tags | No tags attached. | ||||
| Patch | |||||
|
|
did you mean just subset of TeX capab.? just math? it's imho the right way... |
|
|
Was a request. Depends on what people want and what is feasible and reasonable. |
|
|
moved to +1.3 list |
|
|
TeX has some pretty good type magic when it comes to avoiding widows and orphans, reducing wind, etc. |
|
|
Have you seen this? http://www.bluesky.com/mathsetter/index.html It allows TeX into Quark. Very capable. Very powerful. Could it be a path to follow? |
|
|
I'm not sure how TeX/LaTeX's approach can be married to WYSIWIG. IMHO, something like offering a special "LaTeX" frame would do the job nicely. The tool mentioned by Louis seems to do exactly that: Create a frame, insert LaTeX commands and leave the rendering to LaTeX. What I am personally interested in is: How are MathSetter's results represented in the document? Bitmaps? Vectors? What do we see here, DVI, PDF, PS, other? All of this may be important for implementation, I guess. Furthermore, are special environments, styles, document classes etc. necessary? With respect to LaTeX's superb typesetting (here: orphans and widows), it may be worth having a look at the original code to find out *how* LaTeX does it. And at least one look at the OpenOffice.org code might be useful as well, because OOo does an excellent job here (and it is mostly written in C++, like scribus). Just some random thoughts ... |
|
|
MathSetter works with fonts and renders vector. The final output is just *perfect*. I mean, all you can expect from a *professional* font (in the terms Peter Linnell puts it) is there. From computer to plates, a painless workflow. One drawback : it is not simple using *other* fonts, even when they come from a *secure* source. |
|
|
Hi Louis, >> MathSetter works with fonts and renders vector. Does it use an internal QXP vector format? (Maybe the documentation mentions this) >> One drawback : it is not simple using *other* fonts, even when they come from a *secure* source. What do you mean by "other fonts"? Other than LaTeX (Metafont), the fonts provided by the manufacturer? IMHO, using LaTeX fonts for math is no bad idea, since it is more or less standard, and through Postscript, there might be an easy way to get LaTeX as vectors into scribus. But I'm no coder, so that's only a guess. |
|
|
>> Does it use an internal QXP vector format? (Maybe the documentation mentions this) Sorry, this is beyond me. >> What do you mean by "other fonts"? For general use, the fonts provided are OK. When it comes to pick another font (for layout and graphic purposes), Adobe has some extra math fonts and although it is *possible* to use them into MathSetter, the reality is you need to know how fonts are coded to make that work. From the user's perspective, this is less than ideal. This whole thing on Latex being implemented some way into Scribus is something some users will need, sooner or later. The font issue is one part of this. |
|
|
I just found on the inkscape list that someone has created an inkscape extention called latex2svg. Maybe one of the developers wants to have a look. |
|
|
I plan on adding "LaTeX-frames" to Scribus when the current pageitem refactoring has stabilized and I find some time (maybe at the end of the year). This would mean one edits text as LaTeX in the story editor and then Scribus uses LaTeX to render it on the canvas. The preview-package from LaTeX and dvipng should help there. The first version would render TeX frames as PNG images, but later versions might also produce EPS/PDF code for export and printing. What do you think? |
|
|
>>I plan on adding "LaTeX-frames" to Scribus when the current pageitem refactoring has stabilized and I find some time (maybe at the end of the year). Great news!!! >> This would mean one edits text as LaTeX in the story editor and then Scribus uses LaTeX to render it on the canvas. The preview-package from LaTeX and dvipng should help there. Maybe it will be possible to have basic LaTeX support in the SE in the future? Basic LaTeX support means a kind of LateX mode with some special LaTeX buttons (document class etc.), some sort of "mini Kile". This would not be necessary for 1.4, of course. Just one of the "nice to have" features. >>The first version would render TeX frames as PNG images, but later versions might also produce EPS/PDF code for export and printing. I think it is very important that LaTeX will render vectors in the end, so the output can be treated as native scribus vector objects. This way, it would be possible to apply colours, gradients etc. In case you have not done so yet, you might want to have a look at the link provided by Louis (above) to the QXP plugin. That's the way to go, IMHO. |
|
|
>I think it is very important that LaTeX will render vectors in the end, so the output can be treated >as native scribus vector objects. This way, it would be possible to apply colours, gradients etc. Interfacing Scribus style options with TeX will be a hard one. Rotation & scale can easily applied after TeX rendering (we might have to take the slow route via EPS there), but TeX views fonts and colors quite differently from Scribus. Don't expect that Scribus' options for font series/shape/size, lineskip, paragraph options, justification etc. will work in TeX frames. >In case you have not done so yet, you might want to have a look at the link provided by >Louis (above) to the QXP plugin. That's the way to go, IMHO. Hm, I guess you could do similar thinks with my solution. You'd just have a separate set of text options for LaTeX. If you take a look at fntguide.dvi from the LaTeX docs you'll understand why. There might be some Scribus options which could be translated to LaTeX parameters, but I doubt there will ever be a 1:1 correspondence. I'd be happy if I manage to find a way to translate Scribus' fonts into appropiate LaTeX font load commands and find a suitable math font for each... My idea is that you have a normal LaTeX document and Scribus just changes TeX's view of the page size so Scribus can put each LaTeX page into one Scribus texframe. Anything but framesize, scale, rotation and shape would have to be controlled via LaTeX commands. It should be possible to make Scribus fonts and Scribus colors available as LaTeX commands, tho. Note that Scribus 1.3 can have pageitems inside textframes, so it would be possible to have a single LaTeX formula included as an object inside a normal Scribus textframe. |
|
|
Andreas, I'm no coder, so please forgive my amateur thoughts on this point... What I thought of was that Scribus should only provide an interface to LaTeX in the first step: Write LaTeX commands in the SE and let LaTeX do the rendering. At this stage, Scribus style options etc. aren't involved at all. In step two, LaTeX would render vectors (probably Postscript). The result should be a PS/EPS or SVG object (see my posting on the inkscape solution). This way, one wouldn't have to think about mapping fonts and other things. The output would be a pure vector object which could be handled by Scribus (btw, what are Scribus vectors internally, Postscript, SVG, other?). This could save a lot of headaches, couldn't it? What do you think? |
|
|
>What I thought of was that Scribus should only provide an interface to LaTeX in the first step: Write LaTeX commands in the SE and let LaTeX do the rendering. At this stage, Scribus style options etc. aren't involved at all. That's how I plan to do it. Still, LaTeX needs to know the pagesize; or you have to use preview.sty to get pages cropped to the bounding box. >In step two, LaTeX would render vectors (probably Postscript). The result should be a PS/EPS or SVG object (see my posting on the inkscape solution). This way, one wouldn't have to think about mapping fonts and other things. The output would be a pure vector object which could be handled by Scribus (btw, what are Scribus vectors internally, Postscript, SVG, other?). TeX can easily produce EPS, PDF, DVI or PNG. Problem is: Scribus has its own vector format and I don't really trust the EPS->Scribus import path for this. That's why I wanted to use PNG first and sort out the EPS/PDF stuff later. The mapping of fonts is mainly a usability problem: if users want to mix LaTeX frames with ordinary Scribus frames and TextPaths etc, they'd just hate it if they couldn't match fonts and colors between the two, don't you think so? Just consider a Scribus doc where all LaTeX frames use Computer Modern and RGB colors... |
|
|
>>TeX can easily produce EPS, PDF, DVI or PNG. Problem is: Scribus has its own vector format and I don't really trust the EPS->Scribus import path for this. That's why I wanted to use PNG first and sort out the EPS/PDF stuff later. Sounds reasonable. As I understand it, you want to wait until EPS import is more reliable. >>The mapping of fonts is mainly a usability problem: if users want to mix LaTeX frames with ordinary Scribus frames and TextPaths etc, they'd just hate it if they couldn't match fonts and colors between the two, don't you think so? Just consider a Scribus doc where all LaTeX frames use Computer Modern and RGB colors... Well, I don't think it should be possible to mix anything here. LaTeX is LaTeX and I understand that mixing two completely different approaches will be _really_ difficult. Also, LaTeX can render Type 1 and TTF fonts. This would require some configuration on the LaTeX side. Therefore, a detailed instruction in the docs could be a solution. If the LaTeX output will treated exactly as any other EPS, it would be enough, IMHO. Maybe it will also be possible to translate EPS into Scribus' internal vector format. The real question, in my view, is: should LaTeX in Scribus be treated (from the user's point of view) as text or graphics? If it's abundantly clear that LaTeX output is vector only, I don't think it will cause too much confusion, if any. Am I missing something? |
|
|
>Well, I don't think it should be possible to mix anything here. LaTeX is LaTeX and I understand that mixing two completely different approaches will be _really_ difficult. Also, LaTeX can render Type 1 and TTF fonts. This would require some configuration on the LaTeX side. Therefore, a detailed instruction in the docs could be a solution. I think it would be better to make it easy to use the same fonts for LaTeX frames and non-LaTeX frames. AFAIK font installation was/is a bigger issue in LaTeX than it ever were in Scribus. If there is a way to automate it, we should take it. >If the LaTeX output will treated exactly as any other EPS, it would be >enough, IMHO. Maybe it will also be possible to translate EPS into >Scribus' internal vector format. The real question, in my view, is: should >LaTeX in Scribus be treated (from the user's point of view) as text or >graphics? If it's abundantly clear that LaTeX output is vector only, I >don't think it will cause too much confusion, if any. Graphics on canvas, text (LaTeX source) in StoryEditor. That means you will not be able to edit LaTeX text on the canvas, only in SE. We might offer a LaTeXframe->Vectorframe conversion later if someone wants to try special tricks (use "E=m\cdot c^2" as clipping path and stuff like that :-) ) |
|
|
>I think it would be better to make it easy to use the same fonts for LaTeX frames and non-LaTeX frames. AFAIK font installation was/is a bigger issue in LaTeX than it ever were in Scribus. If there is a way to automate it, we should take it. In case you didn't find them already, some available scripts are described here (in German): h++p://www.dante.de/faq/de-tex-faq/html/fonts1.html#26 >Graphics on canvas, text (LaTeX source) in StoryEditor. Exactly. Scribus should also be able to save the LaTeX source code. >That means you will not be able to edit LaTeX text on the canvas, only in SE. In an ideal world, the source code would remain editable in the SE, and the vector output would be editable as any other vector object ;) >. We might offer a LaTeXframe->Vectorframe conversion later if someone wants to try special tricks (use "E=m\cdot c2" as clipping path and stuff like that :-) ) Yes that would be absolutely wonderful :) |
|
|
Ineteresting ! For me this would pretty much be a killer feature. And so for a lot of the scientific community. Actually I found this after producing a very nice scientific poster with scribus and latex. My approach was simple: I wrote a small python script that takes as an argument a tex preambule file, and a tex snipplet file and compile the tex snipplet to a eps or pdf file. Then I insert the file in the scribus document. It works absolutely great. Improvement could be done by turning the save->compile->upddate in one process (I guess this is what you would do), and by providing the size of the frame as the page to LaTeX. Resizing the frame would trigger a re-render of the LaTeX snipplet (I have been told that rendering a LaTeX snipplet is actually rather fast, if the LaTeX preambule is already loaded, you should look at how to do this, maybe pyx could help, I can't check, sourceforge is down). Having the preambule and the TeX snipplet separated allows for a single preamble for all the snipplets where all the colors/fonts get defined. You could provide a default preamble that allows the same fonts to be used in scribus and LaTeX. As a side note I used beamer blocks to make beautiful text blocks in my poster. The result is really nice. I really support this enhancement proposal, and hopefully there isn't to much work, as I was able to hack a half-working demo. Unfortunately I have way to little time to learn scribus codebase and add this feature myself. This could make a lot of promotion for scribus in the scientific communities. I tend to make nice posters and people always ask my how I do them. So far my answer has always been LaTeX+Beamer and people have asked me the source code of the poster, it would be great if I could say: "Scribus, it allows for seamless integration of LaTeX snipplets". Contact me if you want any more suggestions/advice/help about LaTeX (which I know reasonnably well). |
|
2006-11-05 11:13
|
tex_to_eps.py (1,582 bytes)
#!/usr/bin/env python
from optparse import OptionParser as OP
import os, glob
__version__ = "0.0.1"
usage = """usage: %prog [options] texheader texfiles...
Compiles each texfile given as a tex document, using texheader as the
preambule. Outputs eps with tight bounding boxes. Requires latex, ps2eps
and dvips, and epstopdf for pdf output.
By Gael Varoquaux"""
parser = OP(usage=usage, version="%prog " +__version__ )
options, args = parser.parse_args()
if len(args)<2:
print parser.help
sys.exit(1)
tex_header_string = file(args[0]).read()
tex_files = args[1:]
for file_name in tex_files:
print >> file("tex_to_eps_file.tex", "w"), r"""%s
\begin{document}
%s
\end{document}
""" % (tex_header_string, file(file_name).read() )
#os.system("latex -interaction scrollmode tex_to_eps_file")
os.system("latex tex_to_eps_file")
os.system("dvips -Ppdf -G0 tex_to_eps_file.dvi")
os.system("ps2eps -f tex_to_eps_file.ps")
os.environ['GS_OPTIONS'] = "-dUseFlatCompression=true -dPDFSETTINGS=/prepress -sColorImageFilter=FlateEncode -sGrayImageFilter=FlateEncode -dAutoFilterColorImages=false -dAutoFilterGrayImages=false -dEncodeColorImages=false -dEncodeGrayImages=false -dEncodeMonoImages=false"
os.system("epstopdf --nocompress tex_to_eps_file.eps")
# os.system("pdflatex tex_to_eps_file")
# os.system("gs -q -sDEVICE=bbox -dBATCH -dNOPAUSE tex_to_eps_file.pdf")
try:
os.rename("tex_to_eps_file.pdf", file_name[:-4]+".pdf")
except OSError:
pass
map(os.unlink, glob.glob("tex_to_eps_file.*"))
|
|
|
Just added the script I wrote to do this. It is not rocket science but... I have an idea. If you can write the scribus specific part of a plugin (scribus has a python plugin system), that allows me to bottstrap this work, then I might be able to go on with the LaTeX part. I will be able to devellop this only on linux though. And mind you, I can't promise much, I _really_ do have a lot of work, but this project would really be such a killer feature, and does not seem so hard to do. |
|
|
gvaroquaux, this all sounds fabulous. I can't wait to hear from avox and the others on the team about your idea! Would you be able to post a link to this poster you're talking about so we can see it? Can you make it a PDF? |
|
|
I just uploaded the poster at http://gael-varoquaux.info/poster.pdf . Bear in mind this poster was made in one night, a bit in a hurry. And I had never used scribus before (althought I knew about it !). I gave a bit more thought about this idea, and once a LaTeX plugin is created I can probably create a MetaPost plugin (I love Metapost), and a Gnuplot plugin ! This would really make Scribus an absolutly great tool for scientific publishing (and I see there is a Metabug on this issue). Lets not get to carried away on this, but it really looks that this is a low hanging fruit that would give great enhancement. |
|
|
alternative suggestion: A math typesetting plug-in for creating svg data with some additional data for editable equations and aligning of graphics. This plug-in would be able to use WYSIWYG input and latex(subset)/mathml import/export. It should not use fonts but vector graphics as characters/glyphs/operators (perfect math fonts are impossible... read http://www.tug.org/twg/mfg/papers/jkuester/20041002-atypi.pdf ) The plug-in should be written as a detached project with the ability to use it in many other open-source projects. |
|
|
uz1111: nice paper! but I don't think we'll develop such a math plugin... LyX already has a good WYSIWIG math editor, and I'd rather implement an import from there. |
|
|
gvaroquaux: Nice poster! Wish I could read it. Bose-Einstein condensation on an airplane? :) I like your text boxes. I don't know latex, so I'm curious how you made them. I'd like to see scribus support styled frames like that natively at some point, so you could just make a frame, apply the style, enter the text content and you're done. But having plugins for different backend programs would be nice too. I like the plotting idea.... uz1111: Really interesting link about fonts! (Though I'm not quite sure why on earth you would need both normal and italic partial derivative characters.... ;-) I like your suggestion. I had mentioned an idea previously for custom formatting of equations using a general relative placement style framework, that might allow what you want without writing a specific math plugin (see bug 0003672, including my mockup screenshot, for the general idea). The framework would apply to anything from frames to individual characters, and would allow ordered groups of objects to be positioned and formatted according to styles. The user could thus enter an equation as text in a format of their choosing, like f(x)=((x+c)(x-a)^2)/2x, and apply a predefined style that breaks it into relevant formatting groups and positions and formats them as desired. This approach would give the user the ability to design their own equation styles, which could then be shared and modified by others. As the formatting would be native, any available glyphs or shapes could be used and/or transformed as desired for the rendering, and since it's just a style, as-you-type WYSIWYG updates would theoretically be possible.... A much simpler subset of my original proposal would be sufficient here, using something like nested inline frames and/or frame subdivisions (see the recent mailing list discussion on those). Things like extensible glyphs could be handled by simple stretching or by careful subdivision plus some size-to-fit magic. (An integral sign is a fixed-width subdivision on the left side of an equation frame, and is itself divided into fixed-height top and bottom segments and a scalable middle, which is a scribus line. :) The needed features would be placement styles that snap to user-defined characters in text to form subdivision groups; the ability to include predefined content in such a style (like an integral sign or a fraction bar) in place of a given input character; and general subdivision support, which I'm already looking into. You could then have multiple styles to render the same equation as a block or inline, etc., and because the scheme is general it could be adapted to support the same styles in other apps via SVG.... Thoughts? |
|
|
Yes BEC on a plane, with a micro gravity parabola fall. Yes this is crazy ! Tes boxes where made using Beamer, a LaTeX package for presentations. This is what I usually use for presentations. To me it seems that your propositions seem much harder to implement then just sending a bunch text lines to a rendering engine and retrieving the pdf coming out. No parser to do, no understanding of the language, just a call to the rendering engine and a text box to edit the code. Unless the core development team is ready to spend a lot of time on this (which I doubt) we need to make something simple. And LaTeX/Gnuplot/MetaPost already exist and are bloody good at their job. |
|
|
>> "And LaTeX/Gnuplot/MetaPost already exist and are bloody good at their job." Hmm, LaTeX docs look like Nazi text unless you spend hours and hours for better layout. They don't hurt my eyes but they can look way better. "Good" computer science books are often created with Framemaker or DTP soft and you can easily see a difference between them and the most TeX books. People using DTP soft want to have their science papers look like books with mass circulation not like an 80's book written by an average newbie... GNUplot does look good but it still takes too much time making good plots and it cannot be integrated easily into other programs. |
|
|
Bullshit. Nazi texts would use fractur as body font, for one thing. ;-) IMO LaTeX docs do look very uniform, but quite nice anyhow. The default layout is way better than anything you can achieve with Word, unless you spend hours and hours for better layout. That said, LaTeX also has weeknesses. For one thing, most of the design is fixed in the layout format. That's usually better than anything the average user could do, but most users don't bother to look for an alternative layout format (eg. the KomaScript classes) so that most LaTeX docs are based on the default article/book/report classes, which are boring. Another thing that's incredibly hard to do in Tex/LaTeX is creative layout. Even changing the fonts isn't easy, but letting text flow around graphics, doing newspaper layout, tricks with colors and transparency, etc. is near impossible. gvaroquaux did a very nice job with his poster, and it would have been possible to do it just with LaTeX and pstricks, but definitely not in one night. I think using LaTeX for setting text (including math, footnotes, bibliography and indices) and Scribus for the layout would make a very good match. But that means you want Scribus to control the position, size and shape of the textframes, and having access to Scribus's colors and fonts wouldn't be bad, either. I do intend to implement something along the lines I and gvaroquaux described in this thread. Implementing a new math layouter and a WYSIWIG formula editor would be much more work and I really don't see the need for it. |
|
|
>>>Yes BEC on a plane, with a micro gravity parabola fall. Yes this is crazy ! Cool! :-) >>>To me it seems that your propositions seem much harder to implement then just sending a bunch text lines to a rendering engine and retrieving the pdf coming out. >>>Unless the core development team is ready to spend a lot of time on this (which I doubt) we need to make something simple. Agreed. I wasn't saying we shouldn't implement that solution. As I said, I'd love to see plotting integrated if it would work. But not everyone will want to learn latex/etc., and some things will certainly be easier with native support. I'm not suggesting anyone (besides me :) spend a lot of time on a special native layout engine for math or anything else, but I do think that it will become possible automatically as a side effect of a few features I'm investigating adding myself anyway. I don't think it'll really be as hard as it might sound.... ;-) |
|
|
Latex frames and gnuplot support are ready now. I think the children of this bug should better be moved to a general layout-meta-bug, so this bug can be closed. |
|
|
Well done :) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-01-08 23:52 | cbradney | New Issue | |
| 2004-01-10 13:48 | subik | Note Added: 0000177 | |
| 2004-01-10 22:06 | cbradney | Note Added: 0000179 | |
| 2004-01-12 00:12 | cbradney | Priority | normal => low |
| 2004-01-28 21:07 |
|
Note Added: 0000366 | |
| 2004-01-28 21:07 |
|
Product Version | => 1.3 |
| 2004-09-05 19:55 |
|
Note Added: 0002311 | |
| 2004-10-15 15:45 | louisdesjardins | Note Added: 0002707 | |
| 2005-07-03 22:41 | christoph_s | Note Added: 0005381 | |
| 2005-07-04 00:00 | louisdesjardins | Note Added: 0005382 | |
| 2005-07-04 00:40 | christoph_s | Note Added: 0005383 | |
| 2005-07-04 10:04 | louisdesjardins | Note Added: 0005384 | |
| 2005-07-05 02:24 |
|
Status | new => acknowledged |
| 2005-10-21 00:14 | christoph_s | Note Added: 0007162 | |
| 2005-10-22 11:01 | avox | Note Added: 0007178 | |
| 2005-10-22 17:35 | christoph_s | Note Added: 0007181 | |
| 2005-10-22 18:51 | avox | Note Added: 0007182 | |
| 2005-10-22 19:17 | christoph_s | Note Added: 0007183 | |
| 2005-10-22 19:32 | avox | Note Added: 0007184 | |
| 2005-10-22 20:26 | christoph_s | Note Added: 0007185 | |
| 2005-10-22 21:50 | avox | Note Added: 0007186 | |
| 2005-10-22 22:23 | christoph_s | Note Added: 0007187 | |
| 2006-04-12 10:33 | mhanski | Relationship added | related to 0000418 |
| 2006-04-12 10:35 | mhanski | OS | => all |
| 2006-04-12 10:35 | mhanski | OS Version | => all |
| 2006-04-12 10:35 | mhanski | Platform | => all |
| 2006-04-12 10:35 | mhanski | Product Version | 1.3 => 1.3.4cvs |
| 2006-04-12 10:37 | mhanski | Relationship deleted | related to 0000418 |
| 2006-04-12 10:37 | mhanski | Relationship added | parent of 0000418 |
| 2006-04-12 11:04 | mhanski | Relationship added | parent of 0000132 |
| 2006-04-12 11:12 | mhanski | Relationship added | related to 0001172 |
| 2006-04-24 11:50 | mhanski | Relationship added | related to 0003698 |
| 2006-06-07 19:18 | christoph_s | Relationship added | related to 0003896 |
| 2006-11-05 11:11 | gvaroquaux | Note Added: 0013278 | |
| 2006-11-05 11:13 | gvaroquaux | File Added: tex_to_eps.py | |
| 2006-11-05 11:16 | gvaroquaux | Note Added: 0013279 | |
| 2006-11-05 12:40 | louisdesjardins | Note Added: 0013280 | |
| 2006-11-05 12:56 | gvaroquaux | Note Added: 0013283 | |
| 2006-11-09 16:58 | uz1111 | Note Added: 0013343 | |
| 2006-11-09 17:59 | uz1111 | Note Edited: 0013343 | |
| 2006-11-11 02:52 | avox | Note Added: 0013354 | |
| 2006-11-13 21:20 | mkoren | Note Added: 0013394 | |
| 2006-11-16 08:05 | gvaroquaux | Note Added: 0013423 | |
| 2006-11-16 17:11 | uz1111 | Note Added: 0013427 | |
| 2006-11-16 17:13 | uz1111 | Note Edited: 0013427 | |
| 2006-11-16 20:19 | avox | Note Added: 0013428 | |
| 2006-11-16 22:13 | mkoren | Note Added: 0013432 | |
| 2006-11-28 16:26 | christoph_s | Relationship added | related to 0004624 |
| 2008-01-26 12:40 |
|
Status | acknowledged => assigned |
| 2008-01-26 12:40 |
|
Assigned To | => Herm |
| 2008-01-26 12:44 |
|
Note Added: 0018733 | |
| 2008-01-30 12:14 | christoph_s | Relationship deleted | parent of 0000132 |
| 2008-01-30 12:16 | christoph_s | Relationship deleted | parent of 0000418 |
| 2008-01-30 12:46 |
|
Status | assigned => resolved |
| 2008-01-30 12:46 |
|
Fixed in Version | => 1.3.5svn |
| 2008-01-30 12:46 |
|
Resolution | open => fixed |
| 2008-01-30 12:48 | christoph_s | Status | resolved => closed |
| 2008-01-30 12:48 | christoph_s | Note Added: 0018780 |
