incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe_schae...@yahoo.com>
Subject Re: svn commit: r792168 - in /websites/production/openofficeorg: ./ content/openofficeorg/people.html
Date Mon, 04 Jul 2011 18:06:02 GMT
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 <dave2wave@comcast.net>
> To: ooo-dev@incubator.apache.org
> Cc: ooo-commits@incubator.apache.org
> 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 &nbsp; 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 &nbsp; 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 &nbsp;
> > 
> > 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  &nbsp;.  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
> 
> 
> 

Mime
View raw message