User talk:JHenderson
It's not quite readable... I suggest removing font-size: 90%; from the pre rule on the CSS. I tried disabling that property manually with Firebug and it definitely looks more readable. Nicolas 17:30, 9 November 2007 (UTC)
I've removed the font-size: 90%.
chrisc 09:16, 10 November 2007 (UTC)
That looks much better, I also thought it looked a little small. In order to get this to display properly in a fixed-font rather than the default, I did have to change the theme CSS to remove the pre element from the list - the file changed was gumax_template.css - I just commented the pre element out on line 49; doesn't seem to have affected anything else.
Also, to get rid of the PHP error message we were seeing on the preview page, I set the php error_reporting value to 2039 for the ashighlight.class.php script. Kinda an ugly hack, but the returned error had to do with use of an undefined variable in a define call - which seemed odd to me. Again, seems to work, but probably not the most elegant solution.
JHenderson 19:50, 10 November 2007 (UTC)
- Hmm I'm still gettin' it.
Warning: preg_match() [function.preg-match]: Unknown modifier 'p' in /a/httpd/sites/wiki/export/includes/EditPage.php on line 645
Nicolas 03:35, 11 November 2007 (UTC)
- The error you're getting is not the one Jim was referring to. I've fixed the one you're seeing.
- chrisc 04:49, 11 November 2007 (UTC)
- I've fixed the root cause of this warning and removed the error_reporting suppression.
- chrisc 04:49, 11 November 2007 (UTC)
Chris, what was the root cause, and the fix for Nicolas' messge?
JHenderson 05:34, 11 November 2007 (UTC)
- The cause of the issue you saw was that the constant name was not quoted in the define directive. Normally this would mean that you wish to define a constant whose name is the value of the given constant. However since the constant does not exist, PHP guesses that you probably meant to create the constant whose name you gave, so it does it but issues a warning.
- The other issue was caused by an error in the regular expression used for spam protection.
- chrisc 05:38, 11 November 2007 (UTC)
- Ah, OK - that makes sense.
- JHenderson 11:42, 11 November 2007 (UTC)
My page soon will be changed to reflect my first attempt at an import of the docs. I'm working just with the Unix doc as a starting point (seems to be the smallest). The markup isn't yet being parsed - I wanted to start by just doing the raw conversions and deal with the tags later.
I think we probably want to split each "chapter" into its own page, with a TOC at the top for that particular chapter; this is all as a single file, again just as a starting point. So far, so good.
I believe I've sorted out what needs to happen to convert to the XML format used for import/export functionality - changes can be imported as straight XML and show up as revisions to the existing document.
There's still a fair bit of work to be done in converting the tags - as well as any math and image import. Does the file povdgfiles-input contain all the valid tags? If so, that should speed things up a bit.
JHenderson 11:42, 11 November 2007 (UTC)
- Or it would be on this page if the spam filter wasn't blocking it. :-) Seems the a href tags are tripping the spam filter, so I'll have to do some minimal parsing to keep from tripping the filter.
- JHenderson 11:45, 11 November 2007 (UTC)
- yes, you'll need to convert them to wiki syntax. I could make an exception for the docs space, but given it will be open to editing by any user, I think we ought to require wiki syntax from the start.
- chrisc 11:48, 11 November 2007 (UTC)
- Sounds reasonable to me. I'm doing my testing on a local install; so far, it seems to work OK without tag conversion in place yet. Doing the conversion from HTML is going to be a bit more challenging than I initially thought, though, just because the tag can span more than a single line of text.
- JHenderson 12:36, 11 November 2007 (UTC)
POVDOC markup
Had a chat to Thorsten; he suggested the best way to be sure you know all the 'special' tags is to run the existing master doc source through a HTML checker, and have it list all the 'unknown' tags. (You may even want it to list all the 'known' tags as well, so we can get a handle on what is used in the source).
We only allowed limited HTML markup in the doc source so there shouldn't be a large range of standard tags present. Recall that our doc source also outputs to PDF, LATEX, postscript, and plain text. Therefore as a general rule we don't allow things that, if omitted, would render the relevent doc section unusable (though we make exceptions for plain text: since it can't accept any markup or even images, it would restrict the docs too much to make that a baseline).
Some of our non-standard tags could be allowed to remain as-is for the moment. This particularly applies to <indexentry>, since all the associated data is stored as attributes and thus won't be displayed. (To be more HTML compliant, though, we may want to convert all instances of <indexentry> to <indexentry />).