DO NOT REPLY [Bug 52572] collapse-with-precedence throws a NPE
https://issues.apache.org/bugzilla/show_bug.cgi?id=52572 Glenn Adams gad...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Glenn Adams gad...@apache.org 2012-04-14 16:52:32 UTC --- fixed at http://svn.apache.org/viewvc?rev=1326144view=rev, now producing: Apr 14, 2012 10:21:13 AM org.apache.fop.events.LoggingEventListener processEvent WARNING: The following feature isn't implemented by Apache FOP, yet: border-collapse=collapse-with-precedence; defaulting to collapse (on fo:table) (See position 10:94) updated compliance doc to reflect partial implementation of border-collapse thanks pascal! -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 53083] New: update to checkstyle-5.5
https://issues.apache.org/bugzilla/show_bug.cgi?id=53083 Bug #: 53083 Summary: update to checkstyle-5.5 Product: Fop Version: 1.1dev Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: general AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: gad...@apache.org Classification: Unclassified should update build to use checkstyle-5.5 by default, and also remove obsolete checkstyle-4.0 support; -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 53083] update to checkstyle-5.5
https://issues.apache.org/bugzilla/show_bug.cgi?id=53083 Glenn Adams gad...@apache.org changed: What|Removed |Added Priority|P2 |P3 Severity|normal |enhancement -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 53083] update to checkstyle-5.5
https://issues.apache.org/bugzilla/show_bug.cgi?id=53083 Glenn Adams gad...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Glenn Adams gad...@apache.org 2012-04-14 17:12:44 UTC --- http://svn.apache.org/viewvc?rev=1326154view=rev -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: changing default checkstyle to 5.5?
there were no objections, so i have completed this change at https://issues.apache.org/bugzilla/show_bug.cgi?id=53083 On Tue, Apr 10, 2012 at 4:43 PM, Glenn Adams gl...@skynav.com wrote: at present, and for some time now, checkstyle-5.1 has been the default version/configuration we have used on fop; however, now that vincent and i have completed the work to use checkstyle-5.5, i'd like to change the default in build.xml to use the new version are there any objections to doing this? if not, i will make the change by friday
DO NOT REPLY [Bug 53078] [PATCH] Format date to make the lengths independent of DST
https://issues.apache.org/bugzilla/show_bug.cgi?id=53078 Glenn Adams gad...@apache.org changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #1 from Glenn Adams gad...@apache.org 2012-04-14 17:25:55 UTC --- see bug 53077 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 52410] Some warnings/errors are written to stdout instead of stderr
https://issues.apache.org/bugzilla/show_bug.cgi?id=52410
Glenn Adams gad...@apache.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||WORKSFORME
--- Comment #3 from Glenn Adams gad...@apache.org 2012-04-14 17:38:13 UTC ---
not reproducible in 1.1dev (trunk):
bash-3.2$ ${FOP_PATH}/fop test.fo.xml test.pdf
Apr 14, 2012 11:37:06 AM org.apache.fop.events.LoggingEventListener
processEvent
WARNING: The following feature isn't implemented by Apache FOP, yet:
table-layout=auto (on fo:table) (See position 11:37)
Apr 14, 2012 11:37:06 AM org.apache.fop.events.LoggingEventListener
processEvent
INFO: Rendered page #1.
bash-3.2$ ${FOP_PATH}/fop test.fo.xml test.pdf 2/dev/null
bash-3.2$
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
DO NOT REPLY [Bug 51617] No embedded examples is working with FOP.jar 1.0 and JDeveloper 10g
https://issues.apache.org/bugzilla/show_bug.cgi?id=51617 Glenn Adams gad...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #3 from Glenn Adams gad...@apache.org 2012-04-14 18:12:31 UTC --- unable to reproduce in 1.1dev (trunk); see console.log.txt attachment; see also http://svn.apache.org/viewvc?rev=1326166view=rev for minor change to add 'run' target, etc. n.b. from the backtrace in comment 0, i can see that your JDev environment is making use of a different implementation of javax.xml.transform.Transformer than is normally used by FOP: you used: oracle.xml.jaxp.JXTransformer while FOP normally uses: org.apache.xalan.transformer.Transform so I think the problem is that you aren't using xalan-2.7.0.jar as found in $FOP_HOME/lib -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 51617] No embedded examples is working with FOP.jar 1.0 and JDeveloper 10g
https://issues.apache.org/bugzilla/show_bug.cgi?id=51617 --- Comment #4 from Glenn Adams gad...@apache.org 2012-04-14 18:13:21 UTC --- Created attachment 28608 -- https://issues.apache.org/bugzilla/attachment.cgi?id=28608 console output -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 51043] False IPD change with overflow causes UnsupportedOperationException
https://issues.apache.org/bugzilla/show_bug.cgi?id=51043 Andreas L. Delmelle adelme...@apache.org changed: What|Removed |Added Status|NEEDINFO|NEW --- Comment #13 from Andreas L. Delmelle adelme...@apache.org 2012-04-14 19:23:50 UTC --- (In reply to comment #11) andreas, any proposed resolution for this? Two proposals were already mentioned, admittedly rather vague. All that's left is the decision, which should be pretty simple. I would likely have committed the fix and closed the issue last year, if others had not insisted that FOP needs to avoid rounding altogether... There is the so-called 'ideal' or 'proper' solution, which would be a more long-term effort that involves a thorough impact analysis. A switch to values in whatever unit, stored internally as float or double, will have consequences all over the codebase, and for what? Just for the sake of theoretical, mathematical precision --beyond the third decimal, for a value expressed in pt...? Please! :-/ This would cost quite some time and effort for a prize that is hardly worth it in this context. I do not see why FOP would even /need/ that level of precision, given the scale. It's not like FOP is in the business of splitting atoms, so settling on 1/1000pt, internally stored as integers is really not that bad. We are only talking about a few tenths of a µm of difference due to loss in precision, here. Oh well, maybe it's just me... A more 'appropriate' solution, at least from a practical, cost/benefit perspective, would be to simply allow for a margin in the particular comparison triggering the reported issue. The line of code in question in PageBreakingAlgorithm[*] could be made to consider a value of 510237(mpt) as 'equal' to 510236(mpt). Sounds reasonable, keeping in mind that: 1° 'mpt' is an unofficial unit anyway, so FOP determines the calculation rules; why not have 1=2 when counting in those units? 2° converted back to standard units, the loss of 0.001pt would only yield a discernible difference provided that the output resolution is --yep, 72 *thousand* dpi. The latter proposal is a single-line fix for this particular bug entry. The attachment could then basically serve as the only test case, extended with a few other cases, trying out different combinations of attributes/unit specs that yield the largest conceivable rounding differences when run through FixedLength.convert(). [*] line 1138: 'Math.abs (...) = m' instead of '... != 0', where m is half the amount of margin, in 'mpt', within which two page-widths are considered identical. As a suggestion, I mentioned 0.005pt earlier, or around 0.2µm. Interestingly, I found out later that typical light microscopes, assuming visible range light, have a theoretical resolution limit of just about that value. Might count as an argument pro: if your output target supported such a high pixel density, you would probably even miss it /even/ if you looked at it through a conventional microscope. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
