The sample configSettings string below may be helpful. The configSettings string essentially tacks its contents onto the end of the configuration file. If it contains a setting already in the file the new value replaces the old. If it contains a setting not in the file the value is the one which will be used. Note in particular that semanticFiles is a list. String configSettings = "semanticFiles nimas.sem,thisdoc.sem\n" + "style newStyle1\n" + "firstLineIndent 4\n" + "newStyle2\n + "linesBefore 2\n" ; John On Sat, Jul 27, 2013 at 11:26:16AM -0500, John J. Boyer wrote: > The thisdoc.sem file could go in the archive containing the document, so > it is available in future translations. The trranscriber may want to > suspend editing and returdn to it later, so it is important that the > file be saved. > > John > > On Sat, Jul 27, 2013 at 03:58:30AM -0400, Keith Creasy wrote: > > This seems like a good approach. I would just add that we want to try and > > discourage extensive use of new styles. Generally there should already be a > > style that fits most situations. I'm not sure how to accomplish this but if > > a user were to get into the habit of defining a new style every time they > > needed to change the style on an element things could get messy even though > > it might work. There is a very limited number of named elements in most of > > the XML vocabularies we are going to handle and in almost every case the > > named element will use the styles consistently. In most cases it is not a > > matter of creating a new style for a particular element but rather a need to > > assign the treatment of a named element as if it were a different named > > element, for example a particular level-4 heading may really need to be > > treated as a level-3 heading in braille. This is a subjective decision and > > is one reason we still need human transcribers. > > > > > > As Brandon and I discussed, the user interface should present a list of > > available styles that the user can pick from to make it clear that the > > existing styles are available. I think we also need to improve the way > > styles are modified. The current "Translation Template" dialog is OK for > > regular configuration settings but for styles it isn't nearly clear enough > > what the user can do with a style, what settings can be changed, and what > > effect they have. I'd suggest that we leave out styles from the translation > > template dialog or perhaps leave styles there but provide an interface that > > lets a user open a style in a more structured dialog. I think Brandon is > > making this a view in the main window which is also a fine way to make it > > clear to the user what's going on and how to change it. > > > > We may also need to filter the action that is initiated when a user attempts > > to add white space in the text view. One of our testers attempted to center > > a heading with the tab key. The result, as expected, was that the text was > > centered in the text view but the braille view did not change because > > LibLouis compressed the white space. The tester was confused by this > > behavior. > > > > -----Original Message----- > > From: brailleblaster-bounce@xxxxxxxxxxxxx > > [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of John J. Boyer > > Sent: Friday, July 26, 2013 3:35 PM > > To: brailleblaster@xxxxxxxxxxxxx > > Subject: [brailleblaster] Re: Using IDs or Classes in Config files > > > > The least cumbersome way to handle blocks that require special styles would > > be to add the styles to nimas.cfg and make a special semantic-actions file > > for the document with lines such as > > > > newStyle p,id,01 > > > > Then when you call translateFile use a configSettings string like > > > > semanticFiles thisdoc.sem > > > > This will have the effect of including thisdoc.sem at the end of nimas.sem > > > > John > > > > On Fri, Jul 26, 2013 at 01:47:06PM -0400, Brandon Roller wrote: > > > Can I use the semantic actions configfile or configstring? Let's say > > > a paragraph has an id 01 and I want it to have 3 lines before and 2 > > > lines after. > > > With configfile would I make an entry such as configfile > > > p,id,01,newConfig.cfg? > > > With configstring would I make an entry like > > > configstring,p,01,linesBefore=3;linesAfter=3; ? > > > > > > > > > On Fri, Jul 26, 2013 at 1:39 PM, John J. Boyer > > > <john.boyer@xxxxxxxxxxxxxxxxx > > > > wrote: > > > > > > > Brandon, > > > > > > > > References to a particular document belong in the semantic-actions file. > > > > You can add the new style to the configuration file or you could > > > > create a temparary configuration file that includes the "standard" > > > > one and has the new style. This temparary file could also contain a > > > > semanticFiles setting giving the name of a temporary semantics file > > > > for the document which would assign the new style to the paragraph > > > > with its ID. Since the document may contain several paragrraphs > > > > requiring the new style you will need a separate entry in the temporary > > semantic file for each one. > > > > > > > > This is a situation that was not known when liblouisutdml was being > > > > developed. Perhaps a less cumbersome way can be added. > > > > > > > > John > > > > > > > > On Fri, Jul 26, 2013 at 01:06:37PM -0400, Brandon Roller wrote: > > > > > Let's say one specific paragraph has different formatting than the > > > > standard > > > > > para. It is centered and has 3 lines before and 2 lines after. I > > > > > was hoping that I could simply create a new style based off the > > > > > elements > > > > class > > > > > or id attribute. > > > > > > > > > > > > > > > On Fri, Jul 26, 2013 at 12:26 PM, John J. Boyer < > > > > > john.boyer@xxxxxxxxxxxxxxxxx> wrote: > > > > > > > > > > > Brandon, > > > > > > > > > > > > Please give more details. What are you trying to accomplish? > > > > > > > > > > > > John > > > > > > > > > > > > On Fri, Jul 26, 2013 at 09:30:59AM -0400, Brandon Roller wrote: > > > > > > > Is there a way to specify an id or class for special > > > > > > > formatting in a configuration file? I don't see anything in the > > doucmentation. > > > > > > > > > > > > -- > > > > > > John J. Boyer; President, Chief Software Developer > > > > > > Abilitiessoft, Inc. > > > > > > http://www.abilitiessoft.com > > > > > > Madison, Wisconsin USA > > > > > > Developing software for people with disabilities > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > John J. Boyer; President, Chief Software Developer Abilitiessoft, > > > > Inc. > > > > http://www.abilitiessoft.com > > > > Madison, Wisconsin USA > > > > Developing software for people with disabilities > > > > > > > > > > > > > > > > -- > > John J. Boyer; President, Chief Software Developer Abilitiessoft, Inc. > > http://www.abilitiessoft.com > > Madison, Wisconsin USA > > Developing software for people with disabilities > > > > > > > > -- > John J. Boyer; President, Chief Software Developer > Abilitiessoft, Inc. > http://www.abilitiessoft.com > Madison, Wisconsin USA > Developing software for people with disabilities > -- John J. Boyer; President, Chief Software Developer Abilitiessoft, Inc. http://www.abilitiessoft.com Madison, Wisconsin USA Developing software for people with disabilities