Regarding the latest edit of Amarok/Manual/AmarokWindow/PlaylistPane:
Could you please explain what the problem with the recent changes to the Amarok pags was. It is a problematic page, and we need to do something about the placing of images. Anne and I have been trying to make things look decent with little success. The latest attempt using a table is the only thing that has even come close to solving anything.
I agree, of course, that docbook conversion has top priority. Does that mean that we can't use tables for this kind of thing? Perhaps we simply need to force all images to be centered between sections? (That would make this page look very odd.) Any ideas would be much appreciated.
Sorry for not explaining this earlier.
The script is trying to build bijection between two markups. To be clear, the problems with your last edits are as follows
- Script assumes that each raw of the table begins with "| ". Adding <translation> tag gives the XML output "|
Message" That moves Message outside the table in the converted docbook
- KDE docbook commands subset does not have command to scale columns (although generic docbook does). This breaks the current parser (it thinks that "| width="75%" |" is the cell content).
- <br /><br /> is not parsed at all (<para></para><para></para> just triggers the warning).
Surely these problems can be fixed by improving the script. Any help will be appreciated. Instructions can be found here.
P.S. Docbook syntax does not allow using images in captions to images. Please avoid using images templates in the captions. Thanks.
Thanks, this is helpful.
How does KDE docbook handle tables? Is it possible to give some hint of what the column width should be? Could we make, say, 4 colums and then merge 3 of the (an ugly kludge, off course, but if it works...). Or should we avoid tables all together?
Q: Is it possible to give some hint of what the column width should be? A: No, it will be chosen automatically to fit the width. Images will not be scaled down (will be shown as is (100%)).
Q: Could we make, say, 4 colums and then merge 3 of the (an ugly kludge, off course, but if it works...)? A: You could, but the script in its current form does not parse this. Just for the reference the code in docbook for
|Jumping around in code|
|Ctrl+Alt+O||Quick open file: enter part of a filename and select among all the files in the current session's projects' directory trees that match the string; the file will then be opened|
<informaltable> <tgroup cols="2"> <colspec colname="c1"/> <colspec colname="c2"/> <thead> <row> <entry namest="c1" nameend="c2">Jumping around in code</entry> </row> </thead> <tbody> <row> <entry><keycombo>&Ctrl;&Alt;<keycap>O</keycap></keycombo></entry> <entry>Quick open file: enter part of a filename and select among all the files in the current session's projects' directory trees that match the string; the file will then be opened</entry> </row> </tbody> </tgroup> </informaltable>
The problem is in smart parsing for the number of columns to be merged. I have to do it manually for KDevelop manual conversion.
Q: Or should we avoid tables all together? A: No. Generic tables are parsed well. Screenshot
The table width doesn't seem to be as big an issue as I thought. At least when the uploaded images have a sensible size, tables seem to adjust to them nicely.
I tried one more time to make a table to solve the problem, but in a test page User:Claus_chr/Test. Would this work? (apart from the <br /> problem - I havent found out what to do about that yet.)
Update: As a matter of fact I don't need the br tags at all - I just misread the wikimedia docs.
PS. Anne and I was wondering about your comment about images in captions. As far as we know there never was an image in any caption. What are we missing here?
Q: Would this work? A: No. See 1. Can you keep the pipe ("| ") in one unit with the rest of the cell? If you do, then modified script can give something like this.
P.S. I should concentrate on my report now. Can we discuss the rest later? Thanks for your answer.