Ryszard Kubiak <[EMAIL PROTECTED]> wrote: > 9. I don't believe that a single global variable > hyperlatex-in-paragraph may correctly describe > whether we process a paragraph and which one. > The structure od LaTeX documents is recursive > by nature so recursion must be involved > in paragraph recognition. May be continuations > would be appropriate for the purpose...
Yes, this is essentially correct, though I'd certainly wait to hear from you how to use continuations to solve it. The hyperlatex-in-paragraph flag I introduced is not, however, the only conditional flag in the code that controls paragraph placement. But the real problem is that the hyperlatex parser design and HTML semantics are fundamentally different than the TeX parser design and LaTeX semantics. Mostly they match up ok, but where they don't is where the problems lie, even though the differences are slight. My inaction on the <p> bug is born partly of some practical personal circumstances, but mostly it's because I am genuinely uncertain of what the best way to approach the issue is. The uncertainty is made more acute for two reasons. One is that there is a wide variety of browsers out there and they all seem to differ about what is good html. And the second is that none of the obvious (to me) solutions seem to work well, and I hesitate to commit what may become a huge amount of time to developing an ineffective kluge. One approach to fix these issues is to delve a bit deeper and figure out another more subtle condition to check for to deal with list paragraphs, and I am open to suggestions (and I thank Ryszard for the ones he's offered so far). Another approach is to modify the parser to be more like TeX's parser, with a mouth to chew characters, a gullet to swallow tokens and a stomach to digest arguments. This seems to me to have the best chance of being able to tell the difference between macros that don't print anything and the start of new paragraphs, for example. But this is a substantial job. I'd also like to change the way Hyperlatex writes its output right into the same buffer as it's getting its input. This makes the second pass pretty confusing, requires that a substantial number of macros are interpreted twice in exactly the same way, which seems inefficient, and requires protecting characters in such a way that dealing with alternate character sets in a robust way is difficult. But this is also a substantial task, and there may be design issues I don't know about that dictated this choice in the first place. So that's sort of the situation right now. Comments welcome, advice welcome. Thanks, -tom -- ------------------------ tomfool at as220 dot org http://sgouros.com http://whatcheer.net ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Hyperlatex-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hyperlatex-users
