Initial Values of Variables [was: Re: svn commit: r825875 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/cli: CommandLineOptions.java InputHandler.java]

2009-10-20 Thread Vincent Hennebert
Hi,

Just a nit:

 +private boolean useCatalogResolver = false;
 +private EntityResolver entityResolver = null;
 +private URIResolver uriResolver = null;

Those fields are being initialized to their default values. The Java
Language Specification states [1] that every field must be initialized
with a default value, basically 0 for numbers, false for booleans, and
null for objects. So explicitly initializing them with their default
values is just noise.
I’d like to suggest everyone to remove those unnecessary initializations
in the future.

[1] 
http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.12.5

Thanks,
Vincent


Re: Initial Values of Variables [was: Re: svn commit: r825875 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/cli: CommandLineOptions.java InputHandler.java]

2009-10-20 Thread Peter B. West
Yep, they sure are. Does it hurt to spell it out? Like redundant  
parentheses, it does no harm, and makes the code just that little bit  
more explicit, for the dodos like me.


Peter

On 20/10/2009, at 8:13 PM, Vincent Hennebert wrote:


Hi,

Just a nit:


+private boolean useCatalogResolver = false;
+private EntityResolver entityResolver = null;
+private URIResolver uriResolver = null;


Those fields are being initialized to their default values. The Java
Language Specification states [1] that every field must be initialized
with a default value, basically 0 for numbers, false for booleans, and
null for objects. So explicitly initializing them with their default
values is just noise.
I’d like to suggest everyone to remove those unnecessary  
initializations

in the future.

[1] 
http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.12.5

Thanks,
Vincent




DO NOT REPLY [Bug 47941] AFP Renderer Truncates TLE Values

2009-10-20 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=47941

--- Comment #8 from Venkat Reddy vanukuri.ven...@googlemail.com 2009-10-20 
07:12:49 UTC ---
It is better to warn the user atleast when used more than 254 bytes for the TLE
value, so that he will get an idea about the truncation happened because of
lengthy input value.

(In reply to comment #7)
 secondly i tried it with a small testcase holding
 10 TLEs with increasing value length:
 input:
 afp:tag-logical-element name=name250 value=  .../
 afp:tag-logical-element name=name251 value=  ...1/
 afp:tag-logical-element name=name252 value=  ...12/
 afp:tag-logical-element name=name253 value=  ...123/
 afp:tag-logical-element name=name254 value=  ...1234/
 afp:tag-logical-element name=name255 value=  ...12345/
 afp:tag-logical-element name=name256 value=  ...123456/
 afp:tag-logical-element name=name257 value=  ...1234567/
 afp:tag-logical-element name=name258 value=  ...12345678/
 afp:tag-logical-element name=name259 value=  ...123456789/
 the first failure will be for TLE with name name253 and it just looks like 
 a overflow.
 $ grep T36 testcase001.dmp 
   T36: Attribute Value [251]
   T36: Attribute Value [252]
   T36: Attribute Value [253]
   T36: Attribute Value [0]
   T36: Attribute Value [0]
   T36: Attribute Value [0]
   T36: Attribute Value [1]
   T36: Attribute Value [2]
   T36: Attribute Value [3]
   T36: Attribute Value [4]
 in my opinion the best will be to split up such problem TLEs and write out
 several
 TLE structed fields with incremented triplet 0x80 'Sequence Number'. 
 Unfortunately i did no java debugging for the last few years i have first to
 setup 
 eclipse or IntelliJ on my computer.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.


TLE value truncation (AFP extension)

2009-10-20 Thread Venkat Reddy

Hi,

Please help me in finding the code related to this TLE value truncation 
happening for more than 254 bytes. The corresponding bug is already 
raised...


https://issues.apache.org/bugzilla/show_bug.cgi?id=47941

The MODCA documentation clearly states that 254 bytes allowed for the TLE 
value. I would like to take your inputs before digging into the code...

1. Is the behaviour correct (truncating after 254 bytes)?
2. Do we need to warn the user in this case?

Please point me to the code points and guide me to resolve this problem, if you 
can...

Thanks,
Venkat.



License Headers in Test Files? [was: Re: svn commit: r827725 - in /xmlgraphics/fop/branches/Temp_Accessibility/test: accessibility/ accessibility/pdf/ resources/images/]

2009-10-20 Thread Vincent Hennebert
Hi,

In doubt, I added them, but is it actually necessary to put license
headers in such test files? The header is bigger than the actual
content...

Vincent


 Added: 
 xmlgraphics/fop/branches/Temp_Accessibility/test/accessibility/background-image_jpg_repeat.fo
 URL: 
 http://svn.apache.org/viewvc/xmlgraphics/fop/branches/Temp_Accessibility/test/accessibility/background-image_jpg_repeat.fo?rev=827725view=auto
 ==
 --- 
 xmlgraphics/fop/branches/Temp_Accessibility/test/accessibility/background-image_jpg_repeat.fo
  (added)
 +++ 
 xmlgraphics/fop/branches/Temp_Accessibility/test/accessibility/background-image_jpg_repeat.fo
  Tue Oct 20 16:24:44 2009
 @@ -0,0 +1,34 @@
 +?xml version=1.0?
 +!--
 +  Licensed to the Apache Software Foundation (ASF) under one or more
 +  contributor license agreements.  See the NOTICE file distributed with
 +  this work for additional information regarding copyright ownership.
 +  The ASF licenses this file to You under the Apache License, Version 2.0
 +  (the License); you may not use this file except in compliance with
 +  the License.  You may obtain a copy of the License at
 +
 +   http://www.apache.org/licenses/LICENSE-2.0
 +
 +  Unless required by applicable law or agreed to in writing, software
 +  distributed under the License is distributed on an AS IS BASIS,
 +  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 +  See the License for the specific language governing permissions and
 +  limitations under the License.
 +--
 +!-- $Id$ --
 +fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format;
 +  fo:layout-master-set
 +fo:simple-page-master master-name=page
 +  page-height=220pt page-width=320pt margin=10pt
 +  fo:region-body background-image=../resources/images/bgimg72dpi.jpg/
 +/fo:simple-page-master
 +  /fo:layout-master-set
 +  fo:page-sequence master-reference=page language=en country=GB
 +fo:flow flow-name=xsl-region-body hyphenate=true 
 text-align=justify
 +  fo:blockApache FOP (Formatting Objects Processor) is a print 
 formatter driven by XSL 
 +formatting objects (XSL-FO) and an output independent formatter. It 
 is a Java application 
 +that reads a formatting object (FO) tree and renders the resulting 
 pages to a specified 
 +output./fo:block
 +/fo:flow
 +  /fo:page-sequence
 +/fo:root


Re: svn commit: r827023 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/cli/InputHandler.java

2009-10-20 Thread Simon Pepping
On Tue, Oct 20, 2009 at 10:04:09AM -, vhenneb...@apache.org wrote:
 Author: vhennebert
 Date: Tue Oct 20 10:04:09 2009
 New Revision: 827023
 
 URL: http://svn.apache.org/viewvc?rev=827023view=rev
 Log:
 Fixed checkstyle issues.
 Factorized duplicated code into getXMLReader method.
 
 Modified:
 xmlgraphics/fop/trunk/src/java/org/apache/fop/cli/InputHandler.java
 
  /**
 - * Create a catalog resolver and use it for XML parsing and XSLT URI 
 resolution
 + * Creates a catalog resolver and use it for XML parsing and XSLT URI 
 resolution.
   * Try the Apache Commons Resolver, and if unsuccessful,
   * try the same built into Java 6
   */

The above text uses inconsistent language: creates, use, try.

Simon

-- 
Simon Pepping
home page: http://www.leverkruid.eu