Re: org.apache.fop.svg.PDFDocumentGraphics2D can't change page size?

[mehdi houshmand]

Ok well that's at least a little bit related, you need Hyphenation
support in order to run all of the unit tests, which you can find
here:
http://offo.sourceforge.net/

It was put there for licensing reasons.

On 24 October 2011 20:47, Eric Douglas  wrote:
> Of course it doesn't say there were any errors.  The error message says "one 
> or more...errors or were skipped"
>
> I saved the build log.  While it doesn't mention any errors aside from that 
> URI, it does have this near the top:
> compile-hyphenation:
>     [echo] Hyphenation successful
>
> Then this near the bottom:
> hyphenation-present:
>     [echo] Hyphenation Support NOT Present - Layout tests which require 
> hyphenation are NOT being run!
>
> Is that related?  The only other reference to skip is this:
>    [junit] WARNING: Skipping malformed value for font-family: 'Times New 
> 'Roman in "'Times New 'Roman, serif".
>
> -Original Message-
> From: mehdi houshmand [mailto:med1...@gmail.com]
> Sent: Monday, October 24, 2011 3:38 PM
> To: fop-dev@xmlgraphics.apache.org
> Subject: Re: org.apache.fop.svg.PDFDocumentGraphics2D can't change page size?
>
> Curious... The other user was complaining of the same issue... Anyone got any 
> ideas? I can't recreate this.
>
> On 24 October 2011 19:20, Eric Douglas  wrote:
>> I don't know.  After several failed builds and changing to make errors go 
>> away now I get this...
>> Failures: 0, Errors: 0 after every test Only error message I see is
>>    [junit] Oct 24, 2011 1:56:01 PM org.apache.fop.apps.FopFactory
>> resolveURI
>>    [junit] SEVERE: Attempt to resolve URI 
>> 'badprotocol:test/resources/fonts/glb12.ttf.xml' failed:
>>    [junit] javax.xml.transform.TransformerException: Error with URL; base 
>> 'file:/C:/Java/fop-trunk/trunk/test/config/' href 
>> 'badprotocol:test/resources/fonts/glb12.ttf.xml'
>>
>> Then it ends with
>> BUILD FAILED
>> C:\Java\fop-trunk\trunk\build.xml:875: NOTE:
>> **
>> 
>> * One or more of the Junit tests had Failures or Errors or were
>> skipped! *
>> *         Please check the output above for relevant messages.
>> *
>> *    Or use the "junit-reports" target to generate HTML test reports.
>> *
>> **
>> 
>>
>>
>> -Original Message-
>> From: mehdi houshmand [mailto:med1...@gmail.com]
>> Sent: Monday, October 24, 2011 9:28 AM
>> To: fop-dev@xmlgraphics.apache.org
>> Subject: Re: org.apache.fop.svg.PDFDocumentGraphics2D can't change page size?
>>
>> Hi Eric,
>>
>> Could you put up which unit tests are failing. Another user is having a 
>> similar issue.
>>
>> Thanks
>>
>> Mehdi
>>
>> On 24 October 2011 14:05, Eric Douglas  wrote:
>>> Sounds like just what I was looking for!  Thanks!
>>>
>>> I used the TortoiseSVN to download the trunk but I still haven't
>>> figured out how to compile it with ant.  It keeps saying it failed at
>>> least one junit test.
>>> I did just do File > Export in Eclipse, selecting all class files and
>>> got a working jar.
>>>
>>>
>>> -Original Message-
>>> From: Jeremias Maerki [mailto:d...@jeremias-maerki.ch]
>>> Sent: Monday, October 24, 2011 8:46 AM
>>> To: fop-dev@xmlgraphics.apache.org
>>> Subject: Re: org.apache.fop.svg.PDFDocumentGraphics2D can't change
>>> page size?
>>>
>>> Here you go: http://svn.apache.org/viewvc?rev=1188123&view=rev
>>>
>>> In addition to nextPage(), there is now also a nextPage(width,
>>> height) for changing the size of the following pages.
>>>
>>> On 24.10.2011 14:29:23 Eric Douglas wrote:
 It appears the only place it sets the page size is in the
 setupDocument method which also writes the characters to initialize
>>> the PDF.
 I want to be able to put a portrait page and a landscape page in the
 same document, which sort of works if I call that method but it has
 those extra characters which messes up the text though the pages are
 turned correctly.

>>>
>>>
>>>
>>>
>>> Jeremias Maerki
>>>
>>>
>>
>

Re: Merge Request - Temp_ComplexScripts into Trunk

[Glenn Adams]

are you claiming my code is not maintainable by other developers? if so,
then please prove it objectively; otherwise, let's stop talking about this,
and move on with the merge vote

On Tue, Oct 25, 2011 at 1:21 AM, Simon Pepping wrote:

> On Mon, Oct 24, 2011 at 09:05:34PM +0800, Glenn Adams wrote:
> > Sixth, I am going to be maintaining this code. If anyone has a problem
> with
> > specific code during a merge or regression, they merely need ask me.
>
> That is a big no. There will always be a moment when someone else must
> or wants to work on this code. FOP code cannot depend on a single
> person, it must be maintainable by other developers.
>
> Simon
>

RE: org.apache.fop.svg.PDFDocumentGraphics2D can't change page size?

[Eric Douglas]

Of course it doesn't say there were any errors.  The error message says "one or 
more...errors or were skipped"

I saved the build log.  While it doesn't mention any errors aside from that 
URI, it does have this near the top:
compile-hyphenation:
 [echo] Hyphenation successful

Then this near the bottom:
hyphenation-present:
 [echo] Hyphenation Support NOT Present - Layout tests which require 
hyphenation are NOT being run!

Is that related?  The only other reference to skip is this:
[junit] WARNING: Skipping malformed value for font-family: 'Times New 
'Roman in "'Times New 'Roman, serif". 

-Original Message-
From: mehdi houshmand [mailto:med1...@gmail.com] 
Sent: Monday, October 24, 2011 3:38 PM
To: fop-dev@xmlgraphics.apache.org
Subject: Re: org.apache.fop.svg.PDFDocumentGraphics2D can't change page size?

Curious... The other user was complaining of the same issue... Anyone got any 
ideas? I can't recreate this.

On 24 October 2011 19:20, Eric Douglas  wrote:
> I don't know.  After several failed builds and changing to make errors go 
> away now I get this...
> Failures: 0, Errors: 0 after every test Only error message I see is
>    [junit] Oct 24, 2011 1:56:01 PM org.apache.fop.apps.FopFactory 
> resolveURI
>    [junit] SEVERE: Attempt to resolve URI 
> 'badprotocol:test/resources/fonts/glb12.ttf.xml' failed:
>    [junit] javax.xml.transform.TransformerException: Error with URL; base 
> 'file:/C:/Java/fop-trunk/trunk/test/config/' href 
> 'badprotocol:test/resources/fonts/glb12.ttf.xml'
>
> Then it ends with
> BUILD FAILED
> C:\Java\fop-trunk\trunk\build.xml:875: NOTE:
> **
> 
> * One or more of the Junit tests had Failures or Errors or were 
> skipped! *
> *         Please check the output above for relevant messages.           
> *
> *    Or use the "junit-reports" target to generate HTML test reports.    
> *
> **
> 
>
>
> -Original Message-
> From: mehdi houshmand [mailto:med1...@gmail.com]
> Sent: Monday, October 24, 2011 9:28 AM
> To: fop-dev@xmlgraphics.apache.org
> Subject: Re: org.apache.fop.svg.PDFDocumentGraphics2D can't change page size?
>
> Hi Eric,
>
> Could you put up which unit tests are failing. Another user is having a 
> similar issue.
>
> Thanks
>
> Mehdi
>
> On 24 October 2011 14:05, Eric Douglas  wrote:
>> Sounds like just what I was looking for!  Thanks!
>>
>> I used the TortoiseSVN to download the trunk but I still haven't 
>> figured out how to compile it with ant.  It keeps saying it failed at 
>> least one junit test.
>> I did just do File > Export in Eclipse, selecting all class files and 
>> got a working jar.
>>
>>
>> -Original Message-
>> From: Jeremias Maerki [mailto:d...@jeremias-maerki.ch]
>> Sent: Monday, October 24, 2011 8:46 AM
>> To: fop-dev@xmlgraphics.apache.org
>> Subject: Re: org.apache.fop.svg.PDFDocumentGraphics2D can't change 
>> page size?
>>
>> Here you go: http://svn.apache.org/viewvc?rev=1188123&view=rev
>>
>> In addition to nextPage(), there is now also a nextPage(width, 
>> height) for changing the size of the following pages.
>>
>> On 24.10.2011 14:29:23 Eric Douglas wrote:
>>> It appears the only place it sets the page size is in the 
>>> setupDocument method which also writes the characters to initialize
>> the PDF.
>>> I want to be able to put a portrait page and a landscape page in the 
>>> same document, which sort of works if I call that method but it has 
>>> those extra characters which messes up the text though the pages are 
>>> turned correctly.
>>>
>>
>>
>>
>>
>> Jeremias Maerki
>>
>>
>

Re: org.apache.fop.svg.PDFDocumentGraphics2D can't change page size?

[mehdi houshmand]

Curious... The other user was complaining of the same issue... Anyone
got any ideas? I can't recreate this.

On 24 October 2011 19:20, Eric Douglas  wrote:
> I don't know.  After several failed builds and changing to make errors go 
> away now I get this...
> Failures: 0, Errors: 0 after every test
> Only error message I see is
>    [junit] Oct 24, 2011 1:56:01 PM org.apache.fop.apps.FopFactory resolveURI
>    [junit] SEVERE: Attempt to resolve URI 
> 'badprotocol:test/resources/fonts/glb12.ttf.xml' failed:
>    [junit] javax.xml.transform.TransformerException: Error with URL; base 
> 'file:/C:/Java/fop-trunk/trunk/test/config/' href 
> 'badprotocol:test/resources/fonts/glb12.ttf.xml'
>
> Then it ends with
> BUILD FAILED
> C:\Java\fop-trunk\trunk\build.xml:875: NOTE:
> **
> * One or more of the Junit tests had Failures or Errors or were skipped! *
> *         Please check the output above for relevant messages.           *
> *    Or use the "junit-reports" target to generate HTML test reports.    *
> **
>
>
> -Original Message-
> From: mehdi houshmand [mailto:med1...@gmail.com]
> Sent: Monday, October 24, 2011 9:28 AM
> To: fop-dev@xmlgraphics.apache.org
> Subject: Re: org.apache.fop.svg.PDFDocumentGraphics2D can't change page size?
>
> Hi Eric,
>
> Could you put up which unit tests are failing. Another user is having a 
> similar issue.
>
> Thanks
>
> Mehdi
>
> On 24 October 2011 14:05, Eric Douglas  wrote:
>> Sounds like just what I was looking for!  Thanks!
>>
>> I used the TortoiseSVN to download the trunk but I still haven't
>> figured out how to compile it with ant.  It keeps saying it failed at
>> least one junit test.
>> I did just do File > Export in Eclipse, selecting all class files and
>> got a working jar.
>>
>>
>> -Original Message-
>> From: Jeremias Maerki [mailto:d...@jeremias-maerki.ch]
>> Sent: Monday, October 24, 2011 8:46 AM
>> To: fop-dev@xmlgraphics.apache.org
>> Subject: Re: org.apache.fop.svg.PDFDocumentGraphics2D can't change
>> page size?
>>
>> Here you go: http://svn.apache.org/viewvc?rev=1188123&view=rev
>>
>> In addition to nextPage(), there is now also a nextPage(width, height)
>> for changing the size of the following pages.
>>
>> On 24.10.2011 14:29:23 Eric Douglas wrote:
>>> It appears the only place it sets the page size is in the
>>> setupDocument method which also writes the characters to initialize
>> the PDF.
>>> I want to be able to put a portrait page and a landscape page in the
>>> same document, which sort of works if I call that method but it has
>>> those extra characters which messes up the text though the pages are
>>> turned correctly.
>>>
>>
>>
>>
>>
>> Jeremias Maerki
>>
>>
>

RE: org.apache.fop.svg.PDFDocumentGraphics2D can't change page size?

[Eric Douglas]

I'm not sure what it means.  It ends with build failed but it did create a jar.
Now I'm trying to test using this jar and it doesn't seem to like my set font 
commands so I need to figure that out.
 

-Original Message-
From: mehdi houshmand [mailto:med1...@gmail.com] 
Sent: Monday, October 24, 2011 9:28 AM
To: fop-dev@xmlgraphics.apache.org
Subject: Re: org.apache.fop.svg.PDFDocumentGraphics2D can't change page size?

Hi Eric,

Could you put up which unit tests are failing. Another user is having a similar 
issue.

Thanks

Mehdi

On 24 October 2011 14:05, Eric Douglas  wrote:
> Sounds like just what I was looking for!  Thanks!
>
> I used the TortoiseSVN to download the trunk but I still haven't 
> figured out how to compile it with ant.  It keeps saying it failed at 
> least one junit test.
> I did just do File > Export in Eclipse, selecting all class files and 
> got a working jar.
>
>
> -Original Message-
> From: Jeremias Maerki [mailto:d...@jeremias-maerki.ch]
> Sent: Monday, October 24, 2011 8:46 AM
> To: fop-dev@xmlgraphics.apache.org
> Subject: Re: org.apache.fop.svg.PDFDocumentGraphics2D can't change 
> page size?
>
> Here you go: http://svn.apache.org/viewvc?rev=1188123&view=rev
>
> In addition to nextPage(), there is now also a nextPage(width, height) 
> for changing the size of the following pages.
>
> On 24.10.2011 14:29:23 Eric Douglas wrote:
>> It appears the only place it sets the page size is in the 
>> setupDocument method which also writes the characters to initialize
> the PDF.
>> I want to be able to put a portrait page and a landscape page in the 
>> same document, which sort of works if I call that method but it has 
>> those extra characters which messes up the text though the pages are 
>> turned correctly.
>>
>
>
>
>
> Jeremias Maerki
>
>

RE: org.apache.fop.svg.PDFDocumentGraphics2D can't change page size?

[Eric Douglas]

I don't know.  After several failed builds and changing to make errors go away 
now I get this...
Failures: 0, Errors: 0 after every test
Only error message I see is
[junit] Oct 24, 2011 1:56:01 PM org.apache.fop.apps.FopFactory resolveURI
[junit] SEVERE: Attempt to resolve URI 
'badprotocol:test/resources/fonts/glb12.ttf.xml' failed:
[junit] javax.xml.transform.TransformerException: Error with URL; base 
'file:/C:/Java/fop-trunk/trunk/test/config/' href 
'badprotocol:test/resources/fonts/glb12.ttf.xml'

Then it ends with
BUILD FAILED
C:\Java\fop-trunk\trunk\build.xml:875: NOTE:
**
* One or more of the Junit tests had Failures or Errors or were skipped! *
* Please check the output above for relevant messages.   *
*Or use the "junit-reports" target to generate HTML test reports.*
**
 

-Original Message-
From: mehdi houshmand [mailto:med1...@gmail.com] 
Sent: Monday, October 24, 2011 9:28 AM
To: fop-dev@xmlgraphics.apache.org
Subject: Re: org.apache.fop.svg.PDFDocumentGraphics2D can't change page size?

Hi Eric,

Could you put up which unit tests are failing. Another user is having a similar 
issue.

Thanks

Mehdi

On 24 October 2011 14:05, Eric Douglas  wrote:
> Sounds like just what I was looking for!  Thanks!
>
> I used the TortoiseSVN to download the trunk but I still haven't 
> figured out how to compile it with ant.  It keeps saying it failed at 
> least one junit test.
> I did just do File > Export in Eclipse, selecting all class files and 
> got a working jar.
>
>
> -Original Message-
> From: Jeremias Maerki [mailto:d...@jeremias-maerki.ch]
> Sent: Monday, October 24, 2011 8:46 AM
> To: fop-dev@xmlgraphics.apache.org
> Subject: Re: org.apache.fop.svg.PDFDocumentGraphics2D can't change 
> page size?
>
> Here you go: http://svn.apache.org/viewvc?rev=1188123&view=rev
>
> In addition to nextPage(), there is now also a nextPage(width, height) 
> for changing the size of the following pages.
>
> On 24.10.2011 14:29:23 Eric Douglas wrote:
>> It appears the only place it sets the page size is in the 
>> setupDocument method which also writes the characters to initialize
> the PDF.
>> I want to be able to put a portrait page and a landscape page in the 
>> same document, which sort of works if I call that method but it has 
>> those extra characters which messes up the text though the pages are 
>> turned correctly.
>>
>
>
>
>
> Jeremias Maerki
>
>

Re: Merge Request - Temp_ComplexScripts into Trunk

[Simon Pepping]

On Mon, Oct 24, 2011 at 09:05:34PM +0800, Glenn Adams wrote:
> Sixth, I am going to be maintaining this code. If anyone has a problem with
> specific code during a merge or regression, they merely need ask me.

That is a big no. There will always be a moment when someone else must
or wants to work on this code. FOP code cannot depend on a single
person, it must be maintainable by other developers.

Simon

DO NOT REPLY [Bug 46962] [PATCH] Deadlock in PropertyCache class

[bugzilla]

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

--- Comment #13 from Alexis Giotis  2011-10-24 16:59:20 
UTC ---
Now that there was a vote and Mockito has been accepted, what about applying
the patch ? Is there something holding it ?

-- 
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: Merge Request - Temp_ComplexScripts into Trunk

[Pascal Sancho]

Hi,

I'm not sure that short variables names affect readability when long
mathematical formulas are used.
sometimes, code concision can help in understanding what code does:
 depending on what you can read and understand at a glance.
Readability should be in a place between concision and verbose,
depending on the threated topic.

that can be discussed, but this should not prevent from merging GA's works.

+1 for merging it now.

Le 24/10/2011 15:26, Eric Douglas a écrit :
> Short variable names should use less memory, which is mostly irrelevant
> these days.
> In an open project where other people could be working on the same code
> (or other code in the same package) it helps if all names are consistant.
> Personally I could never figure out what variable naming conventions
> are.  Each class I write seems to provide reason to use an entirely new
> convention.
> As long as someone who has never seen your code before can determine the
> purpose of each variable, I'd say you're good.
> If that requires comments, definitely add comments.  When in doubt, comment.
> 
> 
> *From:* Glenn Adams [mailto:gl...@skynav.com]
> *Sent:* Monday, October 24, 2011 9:06 AM
> *To:* fop-dev@xmlgraphics.apache.org
> *Subject:* Re: Merge Request - Temp_ComplexScripts into Trunk
> 
> 
> On Mon, Oct 24, 2011 at 8:26 PM, Georg Datterl  > wrote:
> 
> Hello Glenn,
> 
> > (2) there is no standard for symbol length documented in FOP practice
> > or enforced by checkstyle; I decline to exchange my choice of symbols
> > with longer symbols simply because you prefer it that way; I have
> > offered to add comments to my uses, and that is the most I'm willing
> > to do to address this matter;
> 
> You probably spent more years programming than I am alive, so please
> excuse me if that’s a stupid question: What is the
> reasoning/advantage behind those short variable names?
> 
> 
> First, I don't use short names everywhere. Mostly I just use in local
> variables, but generally not as class variables.
> 
> Second, I was trained in Physics and Mathematics, which uses short
> variable names (E = M C ^ 2).
> 
> Third, I started programming in the 1960s with BAL 360, APL, then
> FORTRAN IV. We use short names there.
> 
> Fourth, I happen to have a good memory and I have no trouble remembering
> the meaning of variable names.
> 
> Fifth, I find that short names prevents making lines too long and gives
> me more room for comments.
> 
> Sixth, I am going to be maintaining this code. If anyone has a problem
> with specific code during a merge or regression, they merely need ask me.
> 
> Seventh, that's just my style, and I assert it is as valid as doing it
> with long names.
> 
> Eighth, asking me to adhere to an undocumented convention that is not
> otherwise enforced, and for which there is no evidence or analysis of
> having been previously followed in FOP contributions is unwarranted.
> 
> Ninth, spending time changing variable names is a waste of time when I
> could be working on adding support for other scripts.
> 
> I can probably throw in a few more random reasons, but this should be
> sufficient.
> 
> I've offered to add comments, take it or leave it.
> 

-- 
Pascal

Re: org.apache.fop.svg.PDFDocumentGraphics2D can't change page size?

[mehdi houshmand]

Hi Eric,

Could you put up which unit tests are failing. Another user is having
a similar issue.

Thanks

Mehdi

On 24 October 2011 14:05, Eric Douglas  wrote:
> Sounds like just what I was looking for!  Thanks!
>
> I used the TortoiseSVN to download the trunk but I still haven't figured
> out how to compile it with ant.  It keeps saying it failed at least one
> junit test.
> I did just do File > Export in Eclipse, selecting all class files and
> got a working jar.
>
>
> -Original Message-
> From: Jeremias Maerki [mailto:d...@jeremias-maerki.ch]
> Sent: Monday, October 24, 2011 8:46 AM
> To: fop-dev@xmlgraphics.apache.org
> Subject: Re: org.apache.fop.svg.PDFDocumentGraphics2D can't change page
> size?
>
> Here you go: http://svn.apache.org/viewvc?rev=1188123&view=rev
>
> In addition to nextPage(), there is now also a nextPage(width, height)
> for changing the size of the following pages.
>
> On 24.10.2011 14:29:23 Eric Douglas wrote:
>> It appears the only place it sets the page size is in the
>> setupDocument method which also writes the characters to initialize
> the PDF.
>> I want to be able to put a portrait page and a landscape page in the
>> same document, which sort of works if I call that method but it has
>> those extra characters which messes up the text though the pages are
>> turned correctly.
>>
>
>
>
>
> Jeremias Maerki
>
>

RE: Merge Request - Temp_ComplexScripts into Trunk

[Eric Douglas]

Short variable names should use less memory, which is mostly irrelevant
these days.
In an open project where other people could be working on the same code
(or other code in the same package) it helps if all names are
consistant.
Personally I could never figure out what variable naming conventions
are.  Each class I write seems to provide reason to use an entirely new
convention.
As long as someone who has never seen your code before can determine the
purpose of each variable, I'd say you're good.
If that requires comments, definitely add comments.  When in doubt,
comment.



From: Glenn Adams [mailto:gl...@skynav.com] 
Sent: Monday, October 24, 2011 9:06 AM
To: fop-dev@xmlgraphics.apache.org
Subject: Re: Merge Request - Temp_ComplexScripts into Trunk



On Mon, Oct 24, 2011 at 8:26 PM, Georg Datterl 
wrote:


Hello Glenn,


> (2) there is no standard for symbol length documented in FOP
practice
> or enforced by checkstyle; I decline to exchange my choice of
symbols
> with longer symbols simply because you prefer it that way; I
have
> offered to add comments to my uses, and that is the most I'm
willing
> to do to address this matter;


You probably spent more years programming than I am alive, so
please excuse me if that's a stupid question: What is the
reasoning/advantage behind those short variable names?



First, I don't use short names everywhere. Mostly I just use in local
variables, but generally not as class variables.

Second, I was trained in Physics and Mathematics, which uses short
variable names (E = M C ^ 2).

Third, I started programming in the 1960s with BAL 360, APL, then
FORTRAN IV. We use short names there.

Fourth, I happen to have a good memory and I have no trouble remembering
the meaning of variable names.

Fifth, I find that short names prevents making lines too long and gives
me more room for comments.

Sixth, I am going to be maintaining this code. If anyone has a problem
with specific code during a merge or regression, they merely need ask
me.

Seventh, that's just my style, and I assert it is as valid as doing it
with long names.

Eighth, asking me to adhere to an undocumented convention that is not
otherwise enforced, and for which there is no evidence or analysis of
having been previously followed in FOP contributions is unwarranted.

Ninth, spending time changing variable names is a waste of time when I
could be working on adding support for other scripts.

I can probably throw in a few more random reasons, but this should be
sufficient.

I've offered to add comments, take it or leave it.

Re: Merge Request - Temp_ComplexScripts into Trunk

[Glenn Adams]

On Mon, Oct 24, 2011 at 8:26 PM, Georg Datterl wrote:

> Hello Glenn,
>
> > (2) there is no standard for symbol length documented in FOP practice
> > or enforced by checkstyle; I decline to exchange my choice of symbols
> > with longer symbols simply because you prefer it that way; I have
> > offered to add comments to my uses, and that is the most I'm willing
> > to do to address this matter;
>
> You probably spent more years programming than I am alive, so please excuse
> me if that’s a stupid question: What is the reasoning/advantage behind those
> short variable names?
>

First, I don't use short names everywhere. Mostly I just use in local
variables, but generally not as class variables.

Second, I was trained in Physics and Mathematics, which uses short variable
names (E = M C ^ 2).

Third, I started programming in the 1960s with BAL 360, APL, then FORTRAN
IV. We use short names there.

Fourth, I happen to have a good memory and I have no trouble remembering the
meaning of variable names.

Fifth, I find that short names prevents making lines too long and gives me
more room for comments.

Sixth, I am going to be maintaining this code. If anyone has a problem with
specific code during a merge or regression, they merely need ask me.

Seventh, that's just my style, and I assert it is as valid as doing it with
long names.

Eighth, asking me to adhere to an undocumented convention that is not
otherwise enforced, and for which there is no evidence or analysis of having
been previously followed in FOP contributions is unwarranted.

Ninth, spending time changing variable names is a waste of time when I could
be working on adding support for other scripts.

I can probably throw in a few more random reasons, but this should be
sufficient.

I've offered to add comments, take it or leave it.

RE: org.apache.fop.svg.PDFDocumentGraphics2D can't change page size?

[Eric Douglas]

Sounds like just what I was looking for!  Thanks!

I used the TortoiseSVN to download the trunk but I still haven't figured
out how to compile it with ant.  It keeps saying it failed at least one
junit test.
I did just do File > Export in Eclipse, selecting all class files and
got a working jar.


-Original Message-
From: Jeremias Maerki [mailto:d...@jeremias-maerki.ch] 
Sent: Monday, October 24, 2011 8:46 AM
To: fop-dev@xmlgraphics.apache.org
Subject: Re: org.apache.fop.svg.PDFDocumentGraphics2D can't change page
size?

Here you go: http://svn.apache.org/viewvc?rev=1188123&view=rev

In addition to nextPage(), there is now also a nextPage(width, height)
for changing the size of the following pages.

On 24.10.2011 14:29:23 Eric Douglas wrote:
> It appears the only place it sets the page size is in the 
> setupDocument method which also writes the characters to initialize
the PDF.
> I want to be able to put a portrait page and a landscape page in the 
> same document, which sort of works if I call that method but it has 
> those extra characters which messes up the text though the pages are 
> turned correctly.
> 




Jeremias Maerki

Re: org.apache.fop.svg.PDFDocumentGraphics2D can't change page size?

[Jeremias Maerki]

Here you go: http://svn.apache.org/viewvc?rev=1188123&view=rev

In addition to nextPage(), there is now also a nextPage(width, height)
for changing the size of the following pages.

On 24.10.2011 14:29:23 Eric Douglas wrote:
> It appears the only place it sets the page size is in the setupDocument
> method which also writes the characters to initialize the PDF.
> I want to be able to put a portrait page and a landscape page in the
> same document, which sort of works if I call that method but it has
> those extra characters which messes up the text though the pages are
> turned correctly.
> 




Jeremias Maerki

org.apache.fop.svg.PDFDocumentGraphics2D can't change page size?

[Eric Douglas]

It appears the only place it sets the page size is in the setupDocument
method which also writes the characters to initialize the PDF.
I want to be able to put a portrait page and a landscape page in the
same document, which sort of works if I call that method but it has
those extra characters which messes up the text though the pages are
turned correctly.

AW: Merge Request - Temp_ComplexScripts into Trunk

[Georg Datterl]

Hello Glenn,

> (2) there is no standard for symbol length documented in FOP practice
> or enforced by checkstyle; I decline to exchange my choice of symbols
> with longer symbols simply because you prefer it that way; I have
> offered to add comments to my uses, and that is the most I'm willing
> to do to address this matter;

You probably spent more years programming than I am alive, so please excuse me 
if that’s a stupid question: What is the reasoning/advantage behind those short 
variable names?

Regards,

Georg Datterl

-- Kontakt --

Georg Datterl

Geneon media solutions gmbh
Gutenstetter Straße 8a
90449 Nürnberg

HRB Nürnberg: 17193
Geschäftsführer: Yong-Harry Steiert

Tel.: 0911/36 78 88 - 26
Fax: 0911/36 78 88 - 20

www.geneon.de

Weitere Mitglieder der Willmy MediaGroup:

IRS Integrated Realization Services GmbH:www.irs-nbg.de
Willmy PrintMedia GmbH:  www.willmy.de
Willmy Consult & Content GmbH:   www.willmycc.de

Re: Merge Request - Temp_ComplexScripts into Trunk

[Glenn Adams]

Vincent,

We apparently disagree on whether coding should be based on ideology or on
practical results. You appear to favor the former, I favor the latter. I
think we will have to leave it at that. I'm not going to alter my
programming style in order to adhere to your notion of ideal programming
practice. It would be one thing if there was an established consensus on
these matters based on objective reasoning, but there is not:

(1) the limit on file length appear to be arbitrary, and not a result of an
explicit reasoned process; i had reasons for coding the way I did (including
the use of nested classes), and I feel no need to alter or justify that
process; if someone can make an objectively reasoned argument on a case by
case basis, then I'm willing to consider refactoring at some point in the
future when other more important tasks are completed; e.g., I would be
willing to break out the nested class UnicodeBidiAlgorithm from
BidiUtil.java into a separate file (which would in address your comment
about separating bidi level determination from reordering);

(2) there is no standard for symbol length documented in FOP practice or
enforced by checkstyle; I decline to exchange my choice of symbols with
longer symbols simply because you prefer it that way; I have offered to add
comments to my uses, and that is the most I'm willing to do to address this
matter;

Note that in both of these cases, I am offering to take concrete steps to
address your comments, though not necessarily in the manner or to the full
extent you would prefer. This is called compromise, an important aspect of
working in a team.

G.

On Mon, Oct 24, 2011 at 6:54 PM, Vincent Hennebert wrote:

> On 22/10/11 01:22, Glenn Adams wrote:
> > inline
> >
> > On Sat, Oct 22, 2011 at 12:04 AM, Chris Bowditch <
> bowditch_ch...@hotmail.com
> >> wrote:
> >
> >>
> >> Since Thunderhead also needs this feature we are willing to invest some
> >> time into it too. Currently my team are telling me it would take 9
> person
> >> months to port this code into our branch of FOP, partly because of some
> >> merge conflicts, but also partly because we are not comfortable with
> some
> >> aspects of the code as it has already been pointed out. The estimate
> would
> >> include the time to refactor long files into small ones, deal with the
> >> variable names and restructuring the code.
> >>
> >
> > I would advise against this, since it would it is functionally
> unnecessary
> > and since it will make future merges more difficult. I will be making
> > additional changes as more features in this area are added.
> >
> > I don't see what refactoring long files into small ones buys you.
> However,
> > if you make a reasoned argument for factoring specific long files (i.e.,
> why
> > such factoring improves architecture, modularity, etc), rather than
> simply
> > say "all long files must be refactored", then I will seriously discuss
> doing
> > so post merge.
>
> When I read this I’m really puzzled because that should really be the
> other way around: what is the reason to keep those classes so big (and
> that must be a really good one)? Most likely the Single Responsibility
> Principle is being violated in those classes.
>
> BidiUtil is a good example of this: it computes Bidi levels on the FO
> tree, /and/ also re-orders areas on the area tree. Those two things
> should most probably be done in two separate classes. Especially since
> from the quick look I had they seem to be using two distinct sets or
> private methods.
>
>
> >> I appreciate your commitment to add comments to short identifiers
> >> declarations, so at least it will be easier for the team to translate
> the
> >> short variables to longer equivalents. Just so we are clear on what you
> >> propose, do you mean this:
> >>
> >> int gi = 0; // Glyph Index
> >>
> >
> > Yes. Note that I already do this in most cases, such as:
> >
> > private static void resolveExplicit ( int[] wca, int defaultLevel, int[]
> ea
> > ) {
> > int[] es = new int [ MAX_LEVELS ];  /* embeddings stack */
> > int ei = 0; /* embeddings stack index
> */
> > int ec = defaultLevel;  /* current embedding
> level
> > */
> > for ( int i = 0, n = wca.length; i < n; i++ ) {
> > int bc = wca [ i ]; /* bidi class of current
> > char */
> > int el; /* embedding level to
> assign
> > to current char */
> > switch ( bc ) {
> > case LRE:   // start left-to-right
> > embedding
> > case RLE:   // start right-to-left
> > embedding
> >  case LRO:   // start
> left-to-right
> > override
> > case RLO:   // start right-to-left
> > override
> > {
> > int en; /* new embedding level */
> > if ( ( 

Re: Merge Request - Temp_ComplexScripts into Trunk

[Vincent Hennebert]

On 22/10/11 01:22, Glenn Adams wrote:
> inline
> 
> On Sat, Oct 22, 2011 at 12:04 AM, Chris Bowditch > wrote:
> 
>>
>> Since Thunderhead also needs this feature we are willing to invest some
>> time into it too. Currently my team are telling me it would take 9 person
>> months to port this code into our branch of FOP, partly because of some
>> merge conflicts, but also partly because we are not comfortable with some
>> aspects of the code as it has already been pointed out. The estimate would
>> include the time to refactor long files into small ones, deal with the
>> variable names and restructuring the code.
>>
> 
> I would advise against this, since it would it is functionally unnecessary
> and since it will make future merges more difficult. I will be making
> additional changes as more features in this area are added.
> 
> I don't see what refactoring long files into small ones buys you. However,
> if you make a reasoned argument for factoring specific long files (i.e., why
> such factoring improves architecture, modularity, etc), rather than simply
> say "all long files must be refactored", then I will seriously discuss doing
> so post merge.

When I read this I’m really puzzled because that should really be the
other way around: what is the reason to keep those classes so big (and
that must be a really good one)? Most likely the Single Responsibility
Principle is being violated in those classes.

BidiUtil is a good example of this: it computes Bidi levels on the FO
tree, /and/ also re-orders areas on the area tree. Those two things
should most probably be done in two separate classes. Especially since
from the quick look I had they seem to be using two distinct sets or
private methods.


>> I appreciate your commitment to add comments to short identifiers
>> declarations, so at least it will be easier for the team to translate the
>> short variables to longer equivalents. Just so we are clear on what you
>> propose, do you mean this:
>>
>> int gi = 0; // Glyph Index
>>
> 
> Yes. Note that I already do this in most cases, such as:
> 
> private static void resolveExplicit ( int[] wca, int defaultLevel, int[] ea
> ) {
> int[] es = new int [ MAX_LEVELS ];  /* embeddings stack */
> int ei = 0; /* embeddings stack index */
> int ec = defaultLevel;  /* current embedding level
> */
> for ( int i = 0, n = wca.length; i < n; i++ ) {
> int bc = wca [ i ]; /* bidi class of current
> char */
> int el; /* embedding level to assign
> to current char */
> switch ( bc ) {
> case LRE:   // start left-to-right
> embedding
> case RLE:   // start right-to-left
> embedding
>  case LRO:   // start left-to-right
> override
> case RLO:   // start right-to-left
> override
> {
> int en; /* new embedding level */
> if ( ( bc == RLE ) || ( bc == RLO ) ) {
> en = ( ( ec & ~OVERRIDE ) + 1 ) | 1;
> } else {
> en = ( ( ec & ~OVERRIDE ) + 2 ) & ~1;
> }
> if ( en < ( MAX_LEVELS + 1 ) ) {
> es [ ei++ ] = ec;
> if ( ( bc == LRO ) || ( bc == RLO ) ) {
> ec = en | OVERRIDE;
> } else {
> ec = en & ~OVERRIDE;
> }
> } else {
> // max levels exceeded, so don't change level or
> override
> }
> el = ec;
> break;
> }
> ...
> 
> What I'm agreeing to do in the relative near future (after merge, before new
> release) is to add such comments to those places where I have not already
> done so, which are probably a minority of such cases.

This is good to hear, although it only marginally helps. Again, what’s
the rationale behind having 2 or 3 letter variables when every course
about programming will emphasise the importance of having reasonably
long, self-describing variable names? What amount of typing is there to
save when any modern IDE will auto-complete variable names?

Explaining the purpose of a variable in a comment creates two problems:
first, it forces the developer to constantly scroll from where the
variable is being used to where it is declared, in order to remember
what its purpose is. By doing so, they lose the context in which the
variable is used and have to read the code again. This makes it
extremely painful and difficult to understand the code.

But more importantly, there is no guarantee that the comment is
accurate. It’s notorious that comments tend to be left behind when
changes are made to the code. Which means that they quickly become
misleading or even plai