RE: [Bug 32253] - Marker bugs
-Original Message- From: Simon Pepping [mailto:[EMAIL PROTECTED] Hi Simon, ...Sorry for the inconvenience in the mean time. You must be joking! Inconvenience? Far from it. The remarks/additions so far have been very helpful. Nobody --ahem, certainly not me-- expects you to solve everything. Thanks for the pointers so far. Greetz, Andreas
Re: [Bug 32253] - Marker bugs
On Wed, Nov 17, 2004 at 02:25:02PM +0100, Luca Furini wrote: Simon Pepping wrote: Marker extends FObjMixed, which adds InlineStackingLM. This is a problem. In the new model there should be a strict separation between LMs implementing InlineLevelLM and those that do not. InlineStackingLM does not, and probably should not do. I still have to really understand InlineStackingLM, I find it very enigmatic! It generates inline areas, but it has LineLM as a subclass ... I think it is only there as a common superclass of InlineLM and LineLM. No FO object should add this LM in its addLM method. Perhaps it should get a private constructor. Currently FObjMixed and BiDiOverride use it. Maybe it should implement both getNextBreakPoss and getNextKnuthElements: looking at the retrieve-marker's parent and / or at the marker's children should be enough to decide whether to call the one or the other. Anyway, I was wondering whether it is really necessary to add a new LM. If the fo tree is fo:page-sequence ---+--- | | fo:static-content fo:flow | | ... ... | | ret. marker's parentmarker's parent | | fo:retrieve-markerfo:marker ---+--- | | chld1 chld2 at the moment, RetrieveMarkerLM tries to achieve this (in the LM tree): ... | parentLM | RetrieveMarkerLM | InlineStackingLM ---+--- | | chldLM1 chldLM2 but, as a marker can only have children which could replace its retrieve-marker, wouldn't it be better to have just: ... | parentLM ---+--- | | chldLM1 chldLM2 I have been thinking along the same lines. fo:wrapper does a similar thing. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
RE: [Bug 32253] - Marker bugs
-Original Message- From: Luca Furini [mailto:[EMAIL PROTECTED] Simon Pepping wrote: Hi Luca / Simon, Marker extends FObjMixed, which adds InlineStackingLM. snip / I still have to really understand InlineStackingLM, I find it very enigmatic! It generates inline areas, but it has LineLM as a subclass ... From the javadoc description, I'm getting the impression that the FObjMixed class was conceived when FOText still subclassed FObj (--correct? In that case, is it still necessary?). In a nutshell, a stroll through the code shows that: The only two places where an InlineStackingLM is created are: - fop.fo.FObjMixed.addLayoutManager() - fop.layoutmgr.PageSequenceLM.getTitleArea() Now, there are eight classes extending FObjMixed: - fop.fo.flow.BidiOverride - fop.fo.flow.Block - fop.fo.flow.Inline - fop.fo.flow.Leader - fop.fo.flow.Marker - fop.fo.flow.RetrieveMarker - fop.fo.flow.Wrapper - fop.fo.pagination.Title WRT FObjMixed.addLM() these eight do the following: - BidiOverride overrides [*] - Block overrides, and adds a BlockLM instead - Inline overrides, and adds an InlineLM instead - Leader overrides, and adds a LeaderLM instead - Marker uses the superclass version - RetrieveMarker overrides and adds a RetrieveMarkerLM instead - Wrapper overrides and lets its children call addLM() (a neutral element) - Title uses the superclass version[**] [*] unsure what it does, but there's mention of moving the logic to BidiOverrideLM, so my best guess is that it would just add a BidiOverrideLM instead [**] actually, looks like it doesn't really use it at all --seems to be handled by PageSequenceLM.getTitleArea() I have, so far, confirmed two cases where trouble occurs: 1. fo:block-fo:inline-fo:block where the deeper fo:block causes a CCE because BlockLM does not implement InlineLevelLM 2. fo:block-fo:retrieve-marker + fo:marker where the retrieved marker causes a CCE because it adds an InlineStackingLM which does not implement InlineLevelLM ... as a marker can only have children which could replace its retrieve-marker, wouldn't it be better to have just: ... | parentLM ---+--- | | chldLM1 chldLM2 That would definitely solve the second case, but still leaves the first. Putting our heads together, we're going to get there, folks! Yes we are :-) Greetz, Andreas
RE: [Bug 32253] - Marker bugs
-Original Message- From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED] snip / That would definitely solve the second case, but still leaves the first. Hmm.. On second thought, that would ultimately depend on: - the parent of fo:retrieve-marker - the child of fo:marker if fo:inline fo:retrieve-marker .../ /fo:inline is combined with fo:marker fo:block.../fo:block /fo:marker It boils down to the first case, so that seems to be the most important one to solve. Greetz, Andreas
RE: FW: DO NOT REPLY [Bug 32201] - please, provide a manpage
-Original Message- From: Glen Mazza [mailto:[EMAIL PROTECTED] --- Andreas L. Delmelle [EMAIL PROTECTED] I'm not too fond of this type of arguments: everybody/nobody else is doing it, so why shouldn't/should we... Hey, I like that argument! For example, no other Apache project is implementing the XSL standard, so why should we?!? Oh...on second thought, I see your point. ;) :) Yeah, OT: My point is actually that it's exactly that kind of thinking that leads people to all sorts of herd-mentality crap, conformist BS and the likes (if you're not too sensitive, not too easily offended, see some examples way below) In short: Nobody seems to think things through anymore, so why should I bother? But if the developers of the other teams involved are quite experienced and preside over successful projects, I frequently defer to their judgment. I won't argue with this. Just use with caution: sometimes people can be 'blinded by experience' --in the sense of: being so used to doing things the wrong way, and actually continually succeeding in that fashion, that they are 'shaped' to never even consider what is actually sane. +0, if you wish to do it. -0 with a manpage. But I still think our future will be with Docbook documentation. Well, if we decide on doing so, it's certainly not top-priority ATM. Let's get this baby walking first, before we buy it a pair of hiking-boots. Personally speaking, it has been wonderful during my day job (which is a lovely 2000 miles away right now ;), our technical writer picked it up very quickly and has been very efficient/quick with it. Even prefers it over Microsoft Word. *Even* ... Microsoft Word (--which 'everybody' uses?) 'Nuff said. :)) Greetz, Andreas Everybody is drinking twenty bottles and mixing it with a cocktail of illegal drugs, so I should too... Everybody goes to a shrink to whine about their miserable excuse for a life and get a prescription for anti-depressants, so maybe I should try it too... Everybody is blowing up buildings and killing innocent people to get their point across, so I should definitely try it too... Everybody is wearing a nazi t-shirt and shaving their head, so I should too... Damn', now they're all settling down, all wearing a suit-and-tie, all venting their aggression caused by the frustration of having to work for a boss who's an utter nitwit and not being able to speak up about it --since nobody does that-- in the weekend, when bashing some cops if their favourite soccer-team loses (or wins, no matter)... well, here I go then :) Everybody has their own crappy, amateuristic, exhibitionist website with links to all sorts of boring stuff, pictures of their ugly self, wife and mongrel-dog, so I should too... Hmm... come to think of it, since everybody seems to have a mongrel-dog, I should get one too --As for the ugly wife? Well, it's an option to be considered. At least, so everybody keeps saying...
DO NOT REPLY [Bug 32201] - please, provide a manpage
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32201. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32201 [EMAIL PROTECTED] changed: What|Removed |Added Priority|P1 |P5 Version|0.20.5 |1.0dev --- Additional Comments From [EMAIL PROTECTED] 2004-11-17 23:45 --- Hi Arnaud, Good news with a 'but': The option of adding a manpage has been discussed on fop-dev, and it seems like there's a good chance that one could be added in the future, although... If it is, it will be so for the next release at the earliest (no prognosis WRT a date so far) In any case, your suggestion is certainly appreciated (as is the attached example, which will serve us well). Thanks for the input! Greetz, Andreas -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
