The existing conversion utils are at https://svn.apache.org/repos/infra/websites/cms/conversion-utilities/
All committers have commit to this section of the infra repos. The anakia2markdown.xslt file in there has entries for table conversion. Gluck. ----- Original Message ---- > From: Dave Fisher <[email protected]> > To: [email protected] > Cc: [email protected] > Sent: Mon, July 4, 2011 1:59:56 PM > Subject: Re: svn commit: r792168 - in /websites/production/openofficeorg: ./ >content/openofficeorg/people.html > > > On Jul 4, 2011, at 9:39 AM, Joe Schaefer wrote: > > <snip> > > >>> Perhaps you can describe "why" you need to do this? > >> > >> Yes. not everyone has a big screen like you. A lot of people have > >> learned >that > > >> eye fatigue is aggravated by reading long lines. > > > > That isn't useful feedback. Useful feedback would be something like: > > the table columns break the text into two rows on whitespace-separated text. > > Or is it the reverse, that you *want* them to break into two rows ( > > in which case you have a bug because that's not what happens on my > > screen)? > > OK. I could have stated my issue more carefully. There are two different >points here. One is overall and the other is specific to this case. > > (1) Overall we should all agree that we design our web content to look in a >narrow window like a laptop. Ten years ago this would be about 600px. Now I >think we should work towards 800px. Then pages work on Tablets, Laptops, etc. > > (2) The intent is for the shorter data in the first three columns to not > wrap >- while the last column is very free-form. When not given widths I find that >html layout gives too much space to this content. > > I now have it controlled by adding to the longest text in columns two >and three. The fourth column only wraps for three people on my 13" laptop and >the table looks like it was done by a professional. > > > > >>> Would simply using between the text words resolve this? > >> > >> Perhaps, so. I'll be experimenting with the headers. But for me knowing >pixels > > >> is a little easier than counting > > > > No that's not what I meant for you to do. What I meant was, look at the > > longest entry in each column and replace the separating whitespace in > > that one entry with . If your problem is columns breaking prematurely > > this will resolve it. > > Yes, this is what I did on my second try. Admittedly this moves the problem. > A >real solution would modify markdown. This is something to think about. > > >>>> Maybe someone should enhance markdown extras. > >>>> > >>>> http://michelf.com/projects/php-markdown/extra/#table > >>>> > >>>> All it can do is control the alignment. Width control ought to be >allowed, > > >> > >>>> either that or an id / class tag to actually tie it in with specific >css. > >>>> > >>>> | Item | Value | > >>>> | ------200 | --:100| > >>>> | Computer | $1600 | > >>>> | Phone | $12 | > >>>> | Pipe | $1 | > >>>> > >>>> Thoughts? > >>> > >>> You do realize that the CMS allows you to do arbitrary things with the > >> markdown, > >>> including preprocessing it before sending it off to the templating >system. > > >> Also > >>> the python markdown parser is extensible, so if you prefer going that > >>> way > > >> and > >>> contributing code to infra we can add a custom extension for everyone > >>> to > >> use. > >> > >> Yes, I do. I am currently thinking about the OOo webcontent and > >> conversion >of > > >> the html. > > > > We have an xslt file somewhere in the conversion-utilities directory > > that converts tables to markdown-style tables, if you decide to go that way > > (and I strongly recommend you do). It's currently embedded in the > > anakia stuff but can easily be extracted. > > Yes. A pointer to existing scripts is great. If you would give me the full >repos path I'll take a look this week. > > You may have noticed that we've started with a webcontent fetch in >ooo/trunk/tools/dev/. > > >> There will be thousand of pages, but hopefully not too many patterns. > >> > >> > >> > >>> > >>>> > >>>> Otherwise I really don't see why it's wrong to have the html table >here. > >>> > >>> If you had examined the content of the table you might have noticed how > >> bloody > >> > >>> awful > >>> the html was (filled with unmatched tags). What you have now is far > >>> more > > >>> maintainable > >>> in a collaborative context- humans make terrible html parsers. > >> > >> Agreed. Not everyone has written lexers and parsers. > >> > >> I'm just frustrated by the movement of the controls. > > > > Change happens. ;-) > > And when two committers are in the same place discussion happens for all to >see! > > Regards, > Dave > > >
