[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sc-dev] p tags in docs




On 19 Dec 2008, at 02:32, jostM wrote:




I don't know what Scott thinks of all this

I think any substitute for or variation on the current approach must:

- Be WYSIWIG editable, more or less, at least in the OSX app
I think a another OSX WYSIWIG html edtitor would be ok. It might save
the trouble trying to recode apple's editor.
- Render consistently in major engines.
- Not be in any way worse than the current situation.
- Have someone willing to convert and maintain it. Half converted
and/or abandoned approaches won't do.

The last is the monster job, and so far nobody has been willing.

Well its not the same as (re) writing them.

Here's a hypthetical scenario:

** someone manages to restrict the OSX editor (or another one) to
somewhere between 5 and 9 divs, 5 <h> levels, links, images, tables,
bold and italic, and <pre>or <code>. No apple tabs and apple spaces etc.

** All of these automatically have the syntax: <TAG class="mySCtagClass">.

** The divs do the paragraph indentation, the <h> levels the titles.

** All these can be accessed by key command or a quick menu or palette.

** Anything in <code> would be automatically syntax colorized.

Then you could easily manually reformat 10-20 help files in an evening.
I recently completely *revised* about 50 of them. That was a big job,
since the longest ones took two full days (there were only a couple,
like View and Document), and usually I could do 2-3 per day. Some had to
be written from scratch. Some involved designing code examples, etc. .

Reformatting an already correctly formatted file, is not that tedious.
Reformatting a badly formatted file takes time. Doing a new help file or
revising one to fit in  a Helper template is a lot of work.  So there
needs to be a mixed approach if something like this is done. We cannot
redo all of the help files as far as content goes. A simple reformatting
scheme is doable.

It also might be possible to write script which would do 90% of the
reformatting, and only need to be corrected a bit. That would really be
ideal.

The help files would look *exactly* like the current templates. And they
could have a dirt simple syntax where you can even read svn diffs
without trouble.

Wrong formatting and double spacing would be completely eliminated.

So then the question is, how many help files are there, and how hard is
it to adjust the OSX editor.

There are well over 1000 help files, so I've figured any non-trivial conversion (i.e. to a structured doc format) would likely be a huge task requiring extensive human work. So far nobody has been willing to do that. It's also a little bit of a concern that you won't really get to test the new system until after that is done. It would certainly have some advantages though.

The OSX editor is easy to adjust in terms of simple things. You don't have access to the html that is generated, but you can edit it afterwards, which already happens a bit.

S.




Maybe some time in the coming year I will look at the latter more
closely. It depends a bit on how my jobs are going, etc. I've been
taking my first baby steps toward this stuff already.


jostM




_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-dev/
search: https://listarc.bham.ac.uk/lists/sc-dev/search/


_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-dev/
search: https://listarc.bham.ac.uk/lists/sc-dev/search/