----- Original Message ---- > From: Dave Fisher <[email protected]> > To: [email protected] > Cc: [email protected] > Sent: Mon, July 4, 2011 12:30:39 PM > Subject: Re: svn commit: r792168 - in /websites/production/openofficeorg: ./ >content/openofficeorg/people.html > > > On Jul 4, 2011, at 9:17 AM, Joe Schaefer wrote: > > > ----- Original Message ---- > > > >> From: Dave Fisher <[email protected]> > >> To: [email protected] > >> Cc: [email protected] > >> Sent: Mon, July 4, 2011 12:09:53 PM > >> Subject: Re: svn commit: r792168 - in /websites/production/openofficeorg: >./ > > >> content/openofficeorg/people.html > >> > >> > >> On Jul 4, 2011, at 8:54 AM, Joe Schaefer wrote: > >> > >>> At 23' full-screen it renders just fine ;-). I'd say try > >>> playing with the min-width css attribute for th or td. > >>> > >>> > >>> You have a choice here of using ooo.css or embedding > >>> a <style type="text/css"> block in the markdown just > >>> before the table. > >> > >> That will be a PITA - each column needs a different minimum width and >there is > > >> no way to differentiate. > > > > 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)? > > 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. > > >> 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. > > 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. ;-)
