Search:   Help



LyX documentation


Shared groups



Categories: Development, GSOC, GSOC2014
<< | Page list | >>

2014 Summer of Code - Ideas Page

LyX 2014 Summer of Code Ideas

If you see an idea here which interests you, please consider contacting the LyX Developer's list. You can send a message to (See instructions on how to subscribe to lyx-devel.) We would love to discuss any thoughts you might have, or to help you put together a student application.

1.  Project: Round trip conversion between LyX and .docx formats

(This project has been approved and it now has its own page: Lyx to Word conversion).

It is important to differentiate the round trip conversion from a normal export. An export aims at converting the LyX file to another format, while maintaining as much of the formating present in the LaTeX / pdf file as possible. This is not the case for round trips: here, the aim is to provide a tool which will be used to convert the .lyx file to a new format, which will result, when converted back to .lyx (i.e. the round trip is completed) an identical .lyx file. Therefore, round trip tools can use metadata files etc which are not readable by the other program in the round trip, but which enable the re-creation of the .lyx file.

This round trip conversion is no solution to do a final lossless conversion from LyX to e.g. docx, but maybe a good starting point.

One use case of this round trip conversion is collaboration with Microsoft office users, i.e. .docx format.

Collaborators often request LyX authors to convert their files to Microsoft Word's .docx format, to edit and comment them and send .docs files back. The design differences between a style-oriented format like LyX's and a format-oriented format like .docx make a full-blown "LyX to .docx" (or "LaTeX to .docx") round trip converter unfeasible (even possibly impossible). The goal of this project is to

  1. develop a framework which enables the conversion of a subset of features of lyx to the other format which, when completing the round trip, result in an identical .lyx file
  2. plan the framework in such a way, so that it is back end (here docx) independent, an can be used for other formats as well after defining the feature set and the converter of these features
  3. include meta-data (possibly in an additional file) which enables the recreation of non-converted features when completing the round trip to lyx

This includes to identify a minimal yet practically useful subset of LyX features that this round trip should support. The actual conversion from LyX to .docx could be implemented by existing multiformat converter (e.g. pandoc), by using LaTeX's own tex4ht Latex-to-OpenDocument format (odt) converter, by using lyx-to-(X)HTML converters (Lyx's native or eLyxer), or by a LyX exporter new tool. If an external converter tool is used, the extraction of the meta data needs to be done in lyx which would result in the creation of a lyx file which can complete the round trip lossless plus a file containing the meta data to re-incorporate the features not supported by the external converter.

Features to be included in the round trip are:

  • sections, headers, ...
  • lists
  • emphasis, bold, ...
  • comments
  • track changes
  • tables and figures?
  • footnotes
  • bibliographic references
  • math?
  • cross-references
  • ... please add more

Other features should be maintained through the meta data and not visible on the docx side.

A subgoal of this project is to develop a minimal yet practically useful subset of LyX features that could be successfully exported to .docx format even if the reverse conversion would be lossy. This feature would be very useful for authors working with publishers who only accept Word-derived formats for the final deliverable. It could also provide useful insights on the requirements necessary for a lossless roundtrip conversion.

Expected Results: A working prototype of a Lyx-to-Word conversion tool and (depending on the chosen strategy) a prototype of the reverse Word-to-Lyx conversion tool

Knowledge Prerequisite: Knowledge of Python is needed for the overall script. Additional programming language knowledge depends on whether the customization of existing external tools is needed. pandoc is written in Haskell, tex4ht is in java, Lyx's native XHTML converter is written in C++, eLyxer is written in Python. Some knowledge of LyX internals is a plus. Knowledge of docx and/or odt xml formats is a bonus.

Prospective Mentor(s): Stefano Franchi, Georg Baum, Rob Oakes


2.  Project: Implement 3-box drawing of insets

Brief Explanation: Insets are a central part of the LyX user interface. They represent embedded content of different kind, such as footnotes, boxes, TeX code, URLs, character styles, notes, etc. Until now, insets are drawn as simple rectangular boxes, either inline (for short content), or displayed (for content that exceeds the embedding line). Especially with longer embedded content, however, the simple rectangular representation is too limited, since the displayed box does not fit the text flow (see fig. 1). This is a major UX flaw, which especially limits the implementation of character styles in LyX. 3-box drawing addresses this by providing (maximally) 3 boxes: box 1 (consisting of max. 1 line) for the line where the inset starts, box 2 (consisting of an unlimited number of lines) for subsequent full width lines of the inset, and box 3 (again consisting of max. 1 line) for the last line of the inset, to which the following embedding text can adjust (see fig. 2).

  |blah                                      blah |  <-- NOTE this ugly hole in the line!
  |+-----+                                        |
  ||inset|                                        |
  || box box box box box box box box box box box ||
  || box box box box box box box box box box box ||
  || box box box box box box box box box box box ||
  || box                                         ||  <-- NOTE this ugly line break!
  |blah blah blah blah blah blah blah blah blah   |

  Fig.1: 1-box drawing (status quo)

  |          +-----+-----------------------------+|
  |blah blah |inset| box 1 box 1 box 1 box 1     ||
  |+---------+-----+                             ||
  || box 2 box 2 box 2 box 2 box 2 box 2 box 2   ||
  || box 2 box 2 box 2 box 2 box 2 box 2 box 2   ||
  ||       +-------------------------------------+|
  || box 3 | blah blah blah blah blah blah blah   |
  |+-------+                                      |
  |blah blah blah blah blah blah blah blah blah   |

  Fig. 2: 3-box drawing (ideal)

The implementation should work both with insets that have a button ("collapsible insets") and with insets without a button ("inline insets", "conglomerate style" insets).

Expected Results: A working implementation of three-box-drawing for insets.

Knowledge Prerequisite: Good knowledge of C++ and Qt are required. Some knowledge of LyX internals is a plus.

Prospective Mentor(s): Ask on lyx-devel

3.  Project: Native support for biblatex

Brief Explanation: Biblatex is the state of the art bibliography/citation package for LaTeX. It is particularly popular amongst LaTeX users from the humanities, since it is much more mighty than any other existing approach. Since it uses a different (LaTeX) UI than traditional bibtex-based packages, it needs a genuine implementation in LyX in order to be natively supported (currently, biblatex can be used with LyX only with the help of some workarounds, and the UI for it is very basic). Biblatex support is one of the most-requested features of LyX users. The goal of the project is to extend LyX's bibliography framework in such a way that biblatex can be fully supported. This requires work in the core (bibliography implementation in LyX) and in the frontend (GUI representation). Note that some basic work to prepare biblatex support has already been done (particularly the introduction of Citation engine modules done by Julien Rioux).

Expected Results: Working biblatex support. Not every single feature needs to be implemented within the project, but LyX should be prepared in a way that the most common functions are there, and that missing functions can be implemented easily.

Knowledge Prerequisite: Knowledge of C++ is required, and while experience with Qt is nice it is by no means required, as it can be learned relatively easily. You will need some command of LaTeX as well, and particularly be(come) familiar with the biblatex package.

Prospective Mentor(s): Ask on lyx-devel.

4.  Project: Overhaul of LyX's converter scheme

Brief Explanation: Currently, LyX's converter mechanism depends on chains of fixed formats. As a result, different converters from LaTeX to PDF, for instance, require different PDF "formats" (pdf1, pdf2, pdf3 etc.). Each of these formats will need to be assigned to a viewer, etc. The goal of the overhaul is that formats can be qualified through flags instead. For example, there would be only one pdf format (and one viewer), but the pdflatex converter would produce pdf:pdlatex format instead of the ugly pdf2. Converters would use the specialized version if available, or a generic one. The idea is that, once you use a converter that has a qualifier, the whole path inherits this qualifier and thus can use different converters. In the context of the overhaul, also LYX's code that handles different latex flavours, which seems pretty fragile, would need to be refactored.

Expected Results: A working prototype of the new converter scheme.

Knowledge Prerequisite: Knowledge of C++ is required. Some knowledge of LyX internals is a plus.

Prospective Mentor(s): Jean-Marc Lasgouttes.

5.  Project: Advanced Find and Replace

Brief Explanation: Advanced Find and Replace is a recently introduced feature almost unique to LyX, allowing for searching formatted text, equations and equation portions, identified either through exact text or regular expressions, with a multitude of options for ignoring or considering some of the formatting during the search. Though, the current implementation is more a proof of concept and has plenty of issues including slowness and non-working corner cases. This project is a proposal for rebuilding such a feature in a well-designed fashion and making it far more usable and useful than it is now. For a better idea of how this feature is intended to work, you can see a few videos showing common use cases:

Expected Results: A reimplementation of Advanced Find and Replace, with a clean and sound design, a fast and usable execution even on large documents, a maintainable and documented code base, supporting the current options, as well as additional options to be better identified through interaction with users/developers on the list.

Knowledge Prerequisite: C++, regular expressions and Qt are required. Some knowledge of LyX internals is a plus.

Prospective Mentor(s): Tommaso Cucinotta

6.  Project: Interactive LyX

Brief Explanation: Extend LyX with interactivity capabilities allowing multiple users to work concurrently on the same LyX document. This is done by adding to LyX the capability to send/receive individual LyX actions (called LFUNs in the LyX gergo) through the network, by making use of some server allowing users to find each other. A proof-of-concept of how such a feature can be started has been sketched out as a patch on the LyX mailing list (see, but it is a bad hack, that stands up only a few secs then it crashes. Key issues in how to guarantee consistency of the concurrent editing, especially when users tend to get closer with their edits, have to be seriously addressed at the design level.

Expected Results: Through some LyX GUI extension, allow remote LyX users to concurrently edit the same LyX document.

Knowledge Prerequisite: C++, Qt, network programming are required. Some knowledge of LyX internals is a plus.

Prospective Mentor(s): Tommaso Cucinotta (primary), Vincent van Ravesteijn (secondary), Jean-Marc Lasgouttes (secondary)

'''Track project progress: InteractiveLyX

Category:Development GSOC GSOC2014

Edit - History - Print - Recent Changes - All Recent Changes - Search
Page last modified on 2017-10-22 17:24 UTC