Ric, It is clear that you mean with good intentions, but for the problem of text representation there is no clear cut ideal solution. There are different browsers, compatibility, different tools to convert text, etc. Even large and expensive commercial systems that provide multi-targeted text handling, as used in MSDN or Apple documentation, don't provide clean solutions suitable for all purposes. Even less would they fit in the economical concepts of handling things in APL/J culture.
So the representation chosen by Roger strikes a compromise between content and representation with simple choice of tags. Looking at http://keiapl.info/ for example, the result is very well organized aesthetically, and achieved with very simple HTML formatting means. I agree with Roger, that it should be possible to revise existing markup incrementally and introduce gradual changes without major disruptions. So approach is not "new format", but stepwise improvement of already good existing format. For example, what Roger was hinting at is finding instances of format-based tags and suggesting a corresponding semantic tag, <font size=+1>Title</font> with <h2>Title</h2> Tables aren't all bad, if viewed as semantic placeholders, as long as you can identify the meaning of particular table or it sells, possibly with a help of class or id attributes, which can also be used for applying CSS replacing <font> or <center>. A bunch of DIVs or LIs paired with CSS tricks aren't so much better. Due to ubiquity of HTML, it makes perfect sense to utilize it as the primary source of the document, which happens to be rendered as is by the browsers. With good choices of tags and attributes, it should be possible to convert it to other formats. Lately there've been many solutions that take HTML, possibly with some hints, and produce PDF directly. Such as Acrobat Professional or HTMLDOC. They can provide TOC with page numbers, etc. > From: "Sherlock, Ric" <[EMAIL PROTECTED]> > > ---Roger Hui wrote: > > I do not apologize for the text being presentation > > oriented. The current presentation looks pretty > > close to exactly what I want to achieve, and > > that presentation is what (I would guess) the > > overwhelming majority of users would see. > > I'm sorry, I tried to convey in my original post that I agreed that the > current > format (i.e. the HTML markup used to produce the visual presentation) of the > dictionary was probably the right idea at the time it was created (when > browsers > didn't support CSS well) in order to provide a consistent presentation to > users. > So I certainly don't think an apology would be in any way appropriate! I am > just > suggesting that a different underlying format of the content might be more > desirable now. > > A new format that more clearly described the structure of the content and how > different parts of the document relate to each other would enable a separate > presentation layer(s) to create visually appropriate results for different > media > (e.g. web-browser, printing, display on small screens or published book (a'la > J > For C)), without having to touch the content of the dictionary at all. > > > If it is impossible to reconstruct the contents > > from the current text I would be moved to do > > something about it. If it is merely difficult then > > working harder and smarter at the reconstruction > > would be the answer. > > Currently the use of tables to create a pleasing visual layout distorts the > content structure in the underlying HTML. I don't know, but suspect that it > will be very difficult (I won't say "impossible" but perhaps "more effort > than > reformatting by hand") to automatically translate the document in its current > form to another format and retain its integrity. My original post and wiki > page > ask for advice from others as to their thoughts on how best to approach that > problem. > > However I figure that before we can best answer how to get from the current > format to a new format, a decision needs to be made as to what the new format > should be. I've tried to suggest a new format by attempting to recreate the > current visual layout of the Dictionary, but using structured markup of the > content (valid HTML) and a separate presentation layer (CSS). Were you > unhappy > with how it looked? > > > I am willing to put in some work to make > > the text more standard. Please make specific > > and individual proposals. For example: > > > > Currently in a vocabulary entry (e.g. d011.htm) > > it says Floor . > > Instead, do this: ... > > And add this ... to the css file > > I tried to go further than that by creating a CSS file and examples of > reformatted pages. I'm not sure that it would be very easy to provide a step > by > step recipe for conversion, but I am prepared to try if that is what you > require. > > > ----- Original Message ----- > > From: Oleg Kobchenko > > > > From: Roger Hui > > > > > [snip] > > > > > > > In your jwiki page > > > > http://www.jsoftware.com/jwiki/RicSherlock/J_Dictionary/CSS_Format > > > > you complained about the exercise numbering, > > > > viz. "2.4" is too hard. Are you serious about > > > > this complaint? > > > > > > It was not a complaint, it was sharing difficulty of > > > reproducing such numbering with CSS automatically. > > Yes thanks Oleg, that was what I intended. I agree that the current numbering > system of the exercises is ideal, but was unable to easily recreate it using > CSS. As Oleg points out, that doesn't mean it isn't possible, merely that my > CSS > expertise was not sufficient. The point I was trying to make on the wiki page > is > that if it was not possible then, in my opinion, it would be better on > balance > to have clean markup than to use any of the cludgy solutions I was able to > come > up with that semi-recreated the current numbering scheme. While I can have an > opinion, the decision on what approach to take quite properly remains with > the > authors. > > > > This is addressed in CCS2 as "Nested counters" > > > http://www.w3.org/TR/REC-CSS2/generate.html#scope > > > > > > Nevertheless, it is possible to reconstruct the > > > semantic intent of structured text based on layout > > > tags, their order is known. A similar problem was > > > addressed in the xml/loose addon as seen in test/dic2.ijs. > > > But such reconstruction is more difficult than having > > > direct indications of content sections. ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
