I have also just discovered how to turn off “Modify styles for single entries” in the DAB program. By default the program does modify the styles, but the user can turn that off.
With your coaching I was able to change the formatting of the example sentences such that the English translations are on a new line. With enough coaching, I might eventually be able to format everything the way I want. I’m not there yet.
Thanks, David, for sharing your progress. I think we all have a lot to learn… The “Modify styles for single entries” is found in the Styles tool, the Modifications tab. I hadn’t seen that before myself, and haven’t had a chance to play with it, but it sounds like it could be useful (and for some, to turn it off). I would encourage you to continue sharing fixes and work-arounds, with examples and screen shots where helpful.
@linguafranka Styles are very powerful, if you understand some CSS (Cascading Styles Sheets), the styles section becomes much less puzzling.
In the digital world HTML and CSS is everywhere. It is in all of the app Builders.
If you start with this page and understand selectors: CSS Selectors
Then look at display property: CSS Layout - The display Property
Then if you look at your XHTML and find the class for a type of data, you will know what selector to use and how to display it as a paragraph rather than an inline set of characters.
The Imported Styles in DAB often have very long selectors but often you can just use the class name as the selector.
If there is one entry you want to target, you can specify an ID of a particular entry to only target that entry. But generally you don’t want to do that.
I have kept working with this, and I can configure FieldWorks to give me an XHTML output that is getting very close to how I want the dictionary data to appear in a cell phone app using Dictionary App Builder. I have to go through multiple iterations to get it the way I like, and others might like to know about the android emulator I am using now. Someone told me about https://www.bignox.com/. Using that, I can double click on an APK file on my computer and see a simulation of how it would appear on my cell phone. That saves me some extra steps and time.
Here is a new screen shot of what I get in a cell phone app, and we will discuss this:
I made two modifications in DAB to get this. The first is that I added a style in the Modifications tab, style name .etymologies, as Ian_McQuay told jheath, and I set it so the display is block. The second modification is what you told me, Ian, adding a .translation style and making it also a block display.
My only remaining problem, I believe, is the vertical spacing. If you look at this sample, you will see that the complex subentry ni lèspwi should be further below what is above and closer to what is below. The same is true for every complex subentry.
I do not have a way to display CSS files with indentation the way you showed, Ian, and I am not too interested in learning how to analyze and edit them, but I am willing to learn how to do style modifications in the Dictionary App Builder program, with some guidance, in order to get the appearance just the way I would like.
Looking good.
In the subentry I found, the subentry is a div, so just adding padding above that should fix the above part.
In your Styles > Imported Styles
.subentry is there in mine. It has a padding-top of 0pt
I’d change that to 12pt to start with. And increase by 6pt if not enough.
The space below is harder. I’d need to see the XHTML. It would also require to view other similar entries to be sure. I assume that Lèspwi Bondyé is also a subentry that should have a smaller space after.
Now some question to think about.
- You are using this abbreviation:
`[< Fr. l’èspwi]’
Why preserve a cryptic abbreviation in the Digital version? Why use the square braces, since it is space delimited in this version, and not like a print dictionary, where you are trying to cryptically separate out parts of the data to preserve space?
If it means From then put:
From:
though it probably means:
From French:
So why not put that? Then we don’t have to know or guess.
-
Similarly for
syn:andopp: -
Immediately below that, I’m puzzled how you got:
syn: Lisentespwi
ni lespwi
The word Lisentespwi is not linked. I’m surprised that you can have an unlinked synonym word that is not in the dictionary. I thought Flex enforced that. In LIFT sourced dictionaries, if there is not link then DAB does not show the word.
Ian, thank you for interacting with me on this. There are several points of discussion.
-
For my Kweyol dictionary in the Dictionary App Builder program using XHTML output from the FieldWorks program, under Styles > Imported Styles I see .subentries mainentrysubentries and .subentry mainentrysubentry (plural and singular), but I do not see simply .subentry. I tried adding padding-top: 18 px to both of those but that did not have any effect. Note also that any time I experiment with the formatting in FieldWorks and make a new XHTML output, the new CSS file is imported into to DAB, and any modifications I had made to the Imported Styles are lost. Any changes I make to Styles > Modifications are persistent. I have finally now uploaded my files if you are interested in seeing them in order to help me. The CSS file can be found at https://www.dbfrank.net/files/KweyolDictionary.css. I don’t know if you need this, but the XHTML file can be found at https://www.dbfrank.net/files/KweyolDictionary.xhtml.
-
I will consider what you say about abbreviations and square or angle brackets in my dictionary, and I may or may not change that. I do understand that you recommend a more vertical and less abbreviated arrangement of the information in the dictionary when it appears digitally such as in a cell phone app.
-
I don’t know why you say that Lisentèspwi is not linked. There are entries in our dictionary for Lisentèspwi and Lèspwi Bondyé and they are linked as synonyms. It may look like they are not linked because Lisentèspwi is in black bold and not indigo bold. But there is a link to that separate entry in the app.
- You just found a bug in the DAB XHTML handling. The entry:
<span class="subentries mainentrysubentries">as handled by DAB as:
.subentries mainentrysubentrieswould not match anything as there is no html element named mainentrysubentries
That would match: .subentries or .mainentrysubentries or .subentries.mainentrysubentries .
So in this case create a Styles > Modification with any of those three and add the padding there.
This is added as a bug in our bug list.
-
-
I probably just misinterpreted what I saw. Glad it is okay. Sorry to waste your time.
Ian, thank you for continuing to try to work with me, but I tried the solution you proposed and it had no effect; the display was the same as before. The only difference was that in FieldWorks, I changed the font setting so that the linked synonyms now show in indigo bold, which was a good suggestion. In DAB I created a Styles > Modification as you said, first with .subentries, then .mainentrysubentries, and then .subentries.mainentrysubentries, each time with a padding-top of 18px and a padding-bottom of 0px, and there was never a change in the display. Here I will show you again:
As an experiment, I did the same thing again but with the singular form: .subentry and .mainentrysubentry, and again there was no effect.
In case it is helpful for your troubleshooting, I have uploaded a fresh version today of my CSS and XHTML files to www.dbfrank.net/files/.
Ian, I have done a lot of study of cascading stylesheets, as you suggested. I have spent a lot of time on this and have made some improvements in how I want the dictionary to appear in a cell phone app, and I have spent a lot of time on other things without getting the results I wanted. Here is the same window I showed before with some slight changes:
I have learned to manipulate the padding-left and padding-right, but not always the padding-top and padding-bottom the way I want. Here is another entry:
Do you see the line in dark blue, lèt konsèv? In terms of vertical spacing, it should be closer to what is below it. I have experimented with different things to try to make that happen but have been unsuccessful. Similarly, the line tiwé lèt should be further away from what is above and closer to what is below. These are subentries, and I believe my frustration is related to what you wrote,
You just found a bug in the DAB XHTML handling. The entry:
<span class="subentries mainentrysubentries">as handled by DAB as:
.subentries mainentrysubentrieswould not match anything as there is no html element named mainentrysubentriesBlockquote
It seems that is why I cannot adjust the padding-top nor the padding-bottom here.
I have a question: Can it work to have the padding-top to be a negative number in order to draw a line closer to what is above it? My experiments in trying to do that have been unsuccessful.
Here are the DAB style modifications I currently have:
I have uploaded the latest revision of my CSS file coming out of FLEx at https://www.dbfrank.net/files/KweyolDictionary.css, but as you have suggested, I am not sharing my dictionary file itself there. I need to turn my attention back to other things now for a while.
I have kept working on this. I am close to being happy with what I have. Here now is the entry for lèspwi:
One thing I am frustrated that I cannot control is the extra space above the cross-reference (“see also”). I get that every time there is a cross-reference, but not when there is a different kind of lexical relation such as synonym (“syn:”), except that if the cross-reference follows a synonym relation, then I don’t get the extra space above. I can find no explanation for this, and I’ve tried a lot of different things.
The other thing I cannot control in this example is the extra space between the minor subentry and the definition that comes after it. I have a few other problems, but these are the main ones remaining for now.
Here are the modifications I currently have:
A curious thing–and somewhat frustrating–is that whenever I make adjustments in FLEx to the styles and then re-load the XHTML and CSS dictionary files into DAB, the modifications that I have made in DAB are changed somewhat. I would have thought that they would stay the way I had them.
Oh, I am having a hard time keeping track of points and pixels and ems and centimeters, so I am trying to put everything as points when I make style modifications in DAB.
Sorry for re-opening this topic. But I am yet again frustrated that DAB isn’t just reproducing the entry format that is in FLEx. Yes, I realize that the default format in FLEx is a print-centric, but that doesn’t mean that a person can’t create a new Dictionary View and make it app-centric. In fact, that’s exactly what I have done - spelling things out instead of using abbreviations, forcing new lines more often, using color, etc. And I worked a lot to get the format the way I want it - and I want that same format in the app.
So if a person works hard to get the format just like they want it in FLEx, exports as XHTML, even opens the XHTML in a browser and confirms that all of the formatting is correct… why can’t DAB just replicate that formatting? Why does it need to modify it at all? Read the thread above to see all of the pain that people are going through to get the output as they want it. But if they can work on the format they want in FLEx, and visually at that (although there are some challenges there, too…), why can’t the app builder NOT mess with that formatting in the layout it produces? Or am I missing something here?
I would say that this is a bug in DAB. If it loads XHTML input, the default format of the data in the app should be identical to that input format. Furthermore, if there is a ProjectDictionaryOverrides.css file (see FLEx help), DAB should be able to suck in those CSS definitions as well.
@Ian_McQuay @linguafranka @Robert @Matthew_Lee @richard
Well, hearing no reaction to my post (I was hoping for at least a weak “Amen” from the cheap seats in the back… 
), I’m assuming that everyone is basically in agreement that this is a problem that should be addressed, as mentioned in the post above. That certainly seems to be in line with the sentiments expressed (along with the frustrations) in the posts throughout this thread.
So I have posted a bug report in the app-builder repo, and I hope to work on this over the next few months (when I find time - this won’t be my main day job… so don’t hold your breath…).
My goal will be to at least have a path by which DAB can produce “exactly” the format of the XHTML file when it is opened in a browser (including any ProjectDictionaryOverrides.css changes). Maybe there should still be an option available to “spread out my print-centric layout”, but I need to figure out first what mechanism DAB is currently using to do that, and see if it makes sense to be able to turn that functionality on and off.
Sorry I wrote a reply but direct to you by email, I thought. But I can’t find it.
I strongly disagree.
If you are formatting a dictionary for print then format it for print. If you are formatting for digital then format it for that medium.
Print has serious restrictions. 1 keep the number of pages down. 2. use abbreviations to help achieve the above by limiting characters. 3. minimize white space.
Questions:
Do we have page restrictions for digital? NO!
Do we need to use abbreviations in digital? NO!
Do we need to minimize white space in digital? NO!
Do you want to make the digital as hard to read for the user as the print? Clearly some compilers do, but why? Surely we want to make it easier.
Does separating the parts of the entry with white space make it easier or harder to find the parts of the entry for the user? I think easier.
SIL has long been a print organization. As we move to digital we need to do things differently to make them appropriate for the medium. Let’s not do it the same because of history. Please think about it and think of the medium, what is the best for the medium and the user.
If Flex was updated to give a good Digital output and a good print output that would be good. But it currently does not. Hence the tweaks that most users were doing with with Styles to make it like the default is.
Let us not publish dictionaries looking the same as print.
I don’t think you understand my intentions, Ian. I am NOT endorsing the use of print-centric format in apps. I am pleading for the ability to precisely define an app-centric format as a Dictionary View in FLEx (completely distinct from any print-centric Views), and then for DAB to use exactly that format without modifying it. You see the pain that @linguafranka went through (above) to try to get the format he wanted. Wouldn’t it be better for users to be able to precisely define the format they want as an app-centric View in FLEx (with its nice graphical interface), and then have DAB duplicate that exact view? (Of course, we will need to train and convince people to abandon their print-centric ideas when they create that view: saving space at all costs, cryptic abbreviations, black-only text, etc.)
This discussion has shifted to the developers thread on Github for the moment, and we’ll get back to you when we come to a resolution… 
I have been out of the discussion on this forum for a long time, but I thought it was time to weigh in again. I completely support what jheath is saying. It would be the most straightforward and simplest solution, as far as I can tell. Let people design their intended output in FLEx and let the Dictionary App reflect that without trying to shape it into something different. I appreciate the Dictionary App Builder program and think it is wonderful, though it has been frustrating for me sometimes as jheath noted, but it doesn’t seem like it should be a burden to ask the program to give the output just as designed in FLEx. The great thing about FLEx is that you can design different outputs for the same data, and you could have one design for print dictionaries and one for dictionary apps. I am an SIL Senior Linguistics Consultant with a specialty in lexicography, and I disagree with the statement that a digital dictionary should look so much different from the print dictionary. For one thing, I prefer to use abbreviations for parts of speech even in a digital dictionary. My Saint Lucian French Creole Dictionary is both in print and as an app, and I prefer for the two to be more alike in appearance than the app easily allows as it is. It seems like it should be an easy solution for the app to allow the option or producing a digital dictionary just as it was designed in FLEx. Ian, you once suggested that if I want to control the appearance of my dictionary in the app, I should learn how to manipulate cascading style sheets. I tried that for a while but gave up because I couldn’t figure out how to do what I want to do. But I have learned FLEx well enough that I can design the output I want in it. For those of us who think they know what they are doing with dictionaries, it would be great to at least having an option of designing our dictionaries in FLEx and getting an app that looks just like that FLEx output. I hope I am not speaking out of turn, because even though I have continued to use DAB in recent years, I have not made note of all the updates, and maybe the program will already to what I am asking.
The thing I missed is what Richard pointed out elsewhere:
We can turn off that behaviour now with the switch on the top of the Modifications tab in the Styles section.
We seem to be coming to a consensus…
- This is a useful functionality, to be able to replicate the XHTML format exactly in the presentation of DAB entries (with the caveat that people should make an effort to create an app-centric format in their Dictionary Views, as discussed above).
- There is already a mechanism available to do that (uncheck the “Modify styles for single entries” box).
Unfortunately, however, there are bugs in that portion of the code so you only get a rough approximation of the XHTML format. (Specifically many of the line breaks go missing, some of the style info gets lost, etc.) I have started attempting to track down and fix some of those problems, so there is hope that we will yet be able to get this functionality working.
We have established that the newlines that are defined by a \A in the Flex before, after, or mid contexts are not currently recognised by DAB in either mode.
I was just coming to that conclusion as well, Ian. Have you tried any other characters, like \0A, \000A, \D, \0D and \000D? Maybe even \a for completeness… If we found something that seemed to work, we could have DAB replace the \A characters, at least temporarily.
I think we also might be able to get the line break with a CSS element of “display:block;”. Can you test an override CSS that includes that, rather than using “\A”? It’s also possible that DAB could look for “\A” at the beginning of the content property value, and convert that into a declaration of display:block.
I don’t know at this point where the problem is. All the web browsers that I’ve tried on Windows seem to be able to handle the \A to force a new line. Is there something about the HTML web viewer in Java used by DAB that is broken?
I don’t have time for testing now. In DAB we were defining display:block; on some classes like to separate the example sentences. The problem is Flex so over specifies the selectors you have to be as precise as the Flex selectors or the styling is ignored. So display:block; does work. That sort of thing is beyond the average user. So the \A is a simpler solution for most users, once they learn it and remember it.