Developers' side bar
<< | Page list | >>
Use these pages for notes/ideas about Google Summer of Code 2008. See also GSoC2011 for the 2011 submission.
Feel free to add more suggestions, as well as adding comments to the various sections. You can move suggestion you feel are less good to the end (with a comment/motivation about it!)
Either standalone or included in LyX
<+1> Charles. Maybe a GUI for the custom paragraph styles
<+1> Martin... though already a HOWTO would help (how much is there in the docs?)
<+1> Pierre. It would be vital. And with color&size handling. (+100)
This could be combined with the layout file editor, and it could also include a semiautomatic wizard that asks a few questions.
<-1> Martin. Nearly impossible to get right. <-1> Richard. Ditto.
Probably too much for a project, since it involves a lot of research and also a lot of code changes. Furthermore the decision process needs tight interaction with core LyX developers, this also makes it less suitable as a project.
<-1> Charles. It is a huge project. GSoC leaves one month, 1.5 month of programming
<-1> Richard. Export to ODF already exists in the form of oolatex, and it's probably possible to adapt Plastex to do it, too. In any event, this isn't really a LyX issue. What one wants is a reliable LaTeX to ODF converter.
<-1> Richard. As with ODF, what is wanted is a reliable LaTeX to HTML (and back) converter. There are now several. There are some issues related to getting them to work properly on different platforms, but in many cases this is due to upstream issues, e.g., the fact that tex4ht has problems on Windows. These are not LyX issues, though of course that's not a reason for someone not to work on them.
Currently no decent converter for WMF/EMF to EPS exists, the existing ones like wvware cannot handle many files.
This code would benefit enormously from a cleanup (or even rewrite from scratch). Also some nice packages could be supported, like colortable or multirow. longtable and booktabs support could be completed.
Relevance: for a document processor for demanding authors, tables are of central importance. The current implementation is not up to snuff and may prevent some from adopting LyX for their professional work.
Tabular-type objects appear in both text and math. The LyX front-end to them is partly unified ("Rows & Colums"), but the back-end logic is mostly separate.
This project involves the text version of tabulars. The LaTeX interface, and functionality, is very versatile and only partly supported by LyX.
Work to be done
The math editor currently has lots of open bugs. There are at least three things to do:
This point can be crucial to facilitate the edition of documents like other common word processor as Word or OpenOffice Writer. Perhaps, this is the main characteristic that many users of LyX are waiting.
This would let you choose the order of LaTeX packages that are put into the preamble, and also disable some if needed.
This is probably not enough for a whole project, since only a bit of code refactoring is needed. Abdel: There is more to it than simple refactoring. The idea would be that tex2lyx fills in LyX internal buffer structure directly instead of outputting to LyX format. LyX itself will take care of the writing to a file. This means that tex2lyx will always stays up to date, no more version lags.
That means to add a number of smaller features (easy) and to take text encodings into account, with full support of encoding switching via \inputencoding and the CJK package (a bit more work).
This can be useful for LyX, tex2lyx and lyx2lyx. It would include a cron jobn that runs the tests automatically from svn, and a web page with the results.
<+1> Charles. Or maybe something similar to the new MsOffice ... Richard. Abdel has just implemented this.
(It's not clear whether this needs to be done. Adding the following to the external-filters.xml file of your beagle distribution will enable Beagle to search .lyx files:
<mimetype>application/x-lyx</mimetype> <extension>.lyx</extension> <command>cat</command> <arguments>%s</arguments>
Currently it is not possible to install LyX by the cmake build system.
Maybe it is possible to merge in Kile as a editor for plain TeX.
Currently LyX only uses Qt, not kdelibs, so it is not optimally integrated into KDE. In future kdelibs will be also available on Mac/Windows, so this would not be a Linux-only project.
<-1> Richard. If this is done at all, it should be an optional part of the build. Users of lower end machines (e.g., me, when I'm working on my old Vaio) may not want to install kdelibs or deal with the overhead.
Use the Google sponsored OCR tesseract for a OCR input dialog. Links:
Work to be done
We can use Lulu for this. Lots of good material already there; we should collect the best, make it consistent, clean it up, and make it look like a book. This is not the same as putting the existing documentation between covers! A book is different.
I see it as the kind of item that I would give to a person that has just discovered his/her need to start using LyX, either personally, or within an organization -- like a journal publisher, a university's publishing service, or the documentation department of a technology company, to mention some. The book should make this initial process smoother. I would hope though that the book would remain a useful reference also after that -- requiring an index.
Should be done via ODF (Open Document Format), which is gaining in popularity and constitutes a gateway away from these legacy formats.
Providing this gateway is again highly relevant in an collaborative authoring context, as it facilitates migration. Collaborative authoring between LyX and OpenOffice users is probably not realistic, due to the paradigmatic differences between the two.
<0> Richard. I'm a little unclear how this is supposed to differ from the Export/Import ODT project. If you can do ODT, then it's just a matter of being able to convert between DOC and ODT, which certainly isn't a LyX issue. For what it's worth, however, the easiest way to implement doc2odt, it seems to me, would be to use the PyUno framework in OOo, and let OOo do the actual work. Indeed, since OOo will convert to LaTeX, you could implement doc2tex the same way.
Will only add little to potential user base. OTOH the embedded form factor brings interesting challenges that may be more generally relevant. Also, this will bring LyX to the attention of yet another community of early adopters; note that for an Open Source project, critical for viability is recruitment, not of end users, but of contributors.
The TeX toolchain up to pdflatex is already available on Maemo.
Prospective mentors: we will need your Google account data for the application. Put it here in transmogrified (non-harvestable) form, or remember to communicate it in private when the time is nigh.
People that could consider being mentors.
This is a tool for planning the next application, for Google Summer of Code 2008.
This uses as example one of the propasals that I (MV) submitted in 2007, which failed. Reasons I suspect for failure are the short time for preparation (it wasn't really a community process) and as a result, a somewhat rambling text. Next time we should do better:
This is the working draft: GSoC2008-lyxtab
Instructions for mentoring orgs:
The deadline for 2007 is past.