Character Arguments a.k.a. Logical Character Styles Lars Gullik Bjønnes <[EMAIL PROTECTED]> 1 Introduction The use of fonts are at present a bit muddled in LyX. LyXFont does not only hold basic font information but it also doubles for other functionality as well. Basic font functionality is: size, shape, family and series. In addition to this LyXFont supports a a couple of Logical Character Styles (LCS): noun and emphasize. LyXFont also supports underline, color, latex and language, I will dub those "physical styles". Without saying anything more about it I want to split LyXFont into two or three classes: TeXFont for basic font functionality, LCS for logical styles and perhaps one for the Physical styles([footnote] We need to decide if we want these physical styles to be in the TeXFont or not.) . LyXFont will not disapear, but rather be changed into a container for the other font classes and responsible for outputing the correct - minimal - code for the underlying format([footnote] latex, linuxdoc or docbook, or other supported formats.) . The rest of this document and of this introdoction will be on the topic of LCS only. We want to be able to support user defined LCS, so that the logical structure of the document will be better. This will make LyX taken advantage of the method used by LaTeX and other conceptual markup languages. Some of these even need LCS to function properly, i.e. DocBook. With LCS the user can create logical styles such as "first-name", "car-brand" or "programming-language". For each of these styles the user will be able to set the font to use, or for more advanced/experienced users the actual LaTeX code to use for the style can be provided. One of the nice things with LCS will then be that to change the visual apparence of "programming-language" for example, will need no change to the document proper, but only a change of the definition of the LCS. 2 Implementation The implementation of LCS will be surprisingly simple and will be possible with only small changes to the rest of the LyX code. The LCS struct will look basically like this: struct LCS { enum Type { font, command }; Type type; string logical_style_name; TeXFont style_font; string style_command; }; It is possible that this struct will be reference counted([footnote] Then the TeXFont will be reference counted too.) , but this is an implemetation detail. The LCS struct will be stored in stl containers, most likely a std::map<string, LCS> will be used where the key is the logical_style_name. We can have global or document local containers for these. LCS used will be stored in the document. The TeXFont is the visual appearence of the LCS. 3 User Interface We need a user interface that will be easy for the user to use, and easier and quicker to use than hardcoded font changes. LCS are after all the preferred way. 3.1 Creating LCS There will be a dialog where the user can set the name of the logical style as well as the font to use for it. It will also be possible to use the LCS command style where the user can provide the name of the command used for the LCS([footnote] What about different documents formats? Can this be handled in a nice way?) , the user has to provide the actual command, either in the preamble or as part of LaTeX or an addon package. Emph and noun will use this method. The storage will be in some configuration file, perhaps .lyxrc. When creating a LCS the user will be able to choose if this is to be user global([footnote] This mean available for all documents of a single user.) or document local([footnote] Only available to this document.) . The system administrator can also choose to create LCS for use by all LyX users on the system. 3.2 Setting LCS The basic method of setting a LCS will be to mark the region of the text that fullfills the LCS criteria. E.g. for the "first-name" style I will mark "Lars Gullik", and then check "First Name" in the LCS drop down list. It should perhaps also be possible to do it like other font setting now. 3.3 Visualization This will probably be the hard part. How should the use of logical styles be visualized on screen? Begin-end dots? Different background color? Drawn inside a box? A note in the minibuffer only? A line on top of the LCS string? For the moment this last one seems best to me, but it is rather intrusive on the display and might very well clutter the screen too much. 4 Unresolved Issues How will this affect LTR, if at all?
