Bug 25646 - [PATCH] line and column numbers on fo:elements
Summary: [PATCH] line and column numbers on fo:elements
Status: CLOSED FIXED
Alias: None
Product: Fop - Now in Jira
Classification: Unclassified
Component: general (show other bugs)
Version: trunk
Hardware: Other other
: P3 enhancement
Target Milestone: ---
Assignee: fop-dev
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-12-19 10:33 UTC by Finn Bock
Modified: 2012-04-01 06:53 UTC (History)
0 users



Attachments
A unified diff against HEAD. (9.35 KB, patch)
2003-12-19 10:34 UTC, Finn Bock
Details | Diff
Unified patch against HEAD (811 bytes, patch)
2003-12-27 14:03 UTC, Finn Bock
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Finn Bock 2003-12-19 10:33:58 UTC
This patch assign line and column number values to the already existing fields 
in FObj and adds a simple toString() method to FObj.
Comment 1 Finn Bock 2003-12-19 10:34:44 UTC
Created attachment 9637 [details]
A unified diff against HEAD.
Comment 2 Glen Mazza 2003-12-23 21:21:34 UTC
Somewhat leery on this one--What are the use cases you're proposing for this?  
Attaching this type of debugging to a heavily-called function such as 
FOTreeBuilder.characters() could be a relatively high performance hit--so I 
want to make sure this passes a "cost-benefit" analysis.  As you see it, what 
are the benefits and what are the costs?

Is this just for testing use or you anticipate this while running in production 
as well?  The latter case, of course, would require more scrutiny.

Also, isn't it more common to store Locator information within the callee?  
I.e., have the FObj.toString() just return information about its inherent data 
to the callee, and let the latter append Locator info (or whatever else callee-
specific) to it--in those areas where we need to do debugging, troubleshooting, 
etc.

Thanks,
Glen
Comment 3 Finn Bock 2003-12-23 21:52:23 UTC
It is purely for debugging and tracing. 

The benefit is easier to read trace output when there is linenumbers, the cost 
is 3 to 4 additional virtual method calls for every fo element.

I can add a test so the methods are only called when running with -d option.

I don't know how the callee of toString() can add line numbers, the line number 
information of the fo elements are only available during the startElement() and 
characters() event.
Comment 4 Glen Mazza 2003-12-26 22:11:28 UTC
OK, I misunderstood--I thought the line/column numbers referred to were of the 
callee (say, at point where it was referencing the particular FObj), not of the 
FO file itself.

This patch looks like a good idea, as I think it will allow us to give very 
solid error feedback for incorrect FO input.  At any rate, if it ever becomes a 
performance issue, it would be fairly simple to remove, or employ a non-
debugging flag as you mention.

Anyway, applied, thanks!

Glen

Comment 5 Finn Bock 2003-12-27 14:02:12 UTC
Please accept my apologies for breaking the build when running with a XMLFilter 
which doesn't gives locator information. A NPE will then occur.

The attached patch fixes the NPE.
Comment 6 Finn Bock 2003-12-27 14:03:05 UTC
Created attachment 9709 [details]
Unified patch against HEAD
Comment 7 Glen Mazza 2003-12-28 16:13:16 UTC
Applied, thanks.
Comment 8 Glenn Adams 2012-04-01 06:53:44 UTC
batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed