https://issues.apache.org/bugzilla/show_bug.cgi?id=51052
Glenn Adams changed:
What|Removed |Added
Status|NEEDINFO|NEW
--
Configure bugmail: https://i
https://issues.apache.org/bugzilla/show_bug.cgi?id=51052
--- Comment #12 from Mehdi Houshmand 2012-04-08 09:13:30
UTC ---
(In reply to comment #11)
> (In reply to comment #0)
> > I've attached an example test FO and I'll attach a patch shortly.
>
> mehdi, any chance you'll be posting a patch?
https://issues.apache.org/bugzilla/show_bug.cgi?id=51052
Glenn Adams changed:
What|Removed |Added
Status|NEW |NEEDINFO
--
Configure bugmail: http
https://issues.apache.org/bugzilla/show_bug.cgi?id=51052
--- Comment #11 from Glenn Adams 2012-04-08 08:40:37 UTC ---
(In reply to comment #0)
> I've attached an example test FO and I'll attach a patch shortly.
mehdi, any chance you'll be posting a patch?
--
Configure bugmail: https://issues.a
https://issues.apache.org/bugzilla/show_bug.cgi?id=51052
Glenn Adams changed:
What|Removed |Added
Priority|P2 |P3
--
Configure bugmail: https://is
https://issues.apache.org/bugzilla/show_bug.cgi?id=51052
--- Comment #10 from Glenn Adams 2012-04-07 01:41:40 UTC ---
resetting P2 open bugs to P3 pending further review
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because:
https://issues.apache.org/bugzilla/show_bug.cgi?id=51052
--- Comment #9 from Mehdi Houshmand 2011-04-18 03:42:47 EDT
---
> I am far from convinced that this justifies the added computational complexity
> of walking up the tree, and checking all static-contents for a retrieve-marker
> that _might
https://issues.apache.org/bugzilla/show_bug.cgi?id=51052
--- Comment #8 from Andreas L. Delmelle 2011-04-16
16:06:21 EDT ---
(In reply to comment #6)
> > Well, I guess that would depend on how this was implemented. If we were
> > being
> > puritanical, one could argue that if FOText was an obje
https://issues.apache.org/bugzilla/show_bug.cgi?id=51052
--- Comment #7 from Andreas L. Delmelle 2011-04-16
14:54:27 EDT ---
(In reply to comment #6)
> In the same sense, one could reason that the marker's child blocks, tables,
> lists etc. all should not be created, and we should store the FO s
https://issues.apache.org/bugzilla/show_bug.cgi?id=51052
--- Comment #6 from Andreas L. Delmelle 2011-04-16
14:35:44 EDT ---
(In reply to comment #5)
> Well, I guess that would depend on how this was implemented. If we were being
> puritanical, one could argue that if FOText was an object repres
https://issues.apache.org/bugzilla/show_bug.cgi?id=51052
--- Comment #5 from Mehdi Houshmand 2011-04-15 04:40:37 EDT
---
> That might be an option. Store the char array, and later on, trigger
> characters() on the retrieve-marker, if appropriate.
> However, I believe it is not strictly necessary
https://issues.apache.org/bugzilla/show_bug.cgi?id=51052
--- Comment #4 from Andreas L. Delmelle 2011-04-14
14:45:35 EDT ---
(In reply to comment #3)
> However, o.a.f.fo.flow.Marker inherits from FObjMixed, and so when
> Marker.characters() is called, it blindly creates an FOText object without
https://issues.apache.org/bugzilla/show_bug.cgi?id=51052
--- Comment #3 from Mehdi Houshmand 2011-04-14 04:08:22 EDT
---
After further looking into this, it appears as if the validateChildNode() was
never intended to validate #PCDATA (or in our its object representation
FOText). I say this becau
https://issues.apache.org/bugzilla/show_bug.cgi?id=51052
--- Comment #2 from Andreas L. Delmelle 2011-04-13
13:35:07 EDT ---
(In reply to comment #1)
> ... If some bare text is entered in a fo:table-cell (or basically any FO that
> expects block-content), then it will be ignored, rather than rep
https://issues.apache.org/bugzilla/show_bug.cgi?id=51052
--- Comment #1 from Andreas L. Delmelle 2011-04-13
13:25:05 EDT ---
(In reply to comment #0)
> The issue is that a NPE is thrown when a retrieve-marker retrieves a marker
> with only text content, when the retrieve-marker is a child of a t
15 matches
Mail list logo
