Re: Style issues.
> >> if ((bp = getNextBreakPoss(childLC, null)) != null) {
> > Probably comes from long years of writing C and C++ and avoiding extra
> > lines of code. Must be taste since I don't find it that bad, but if we
> > all vote it out in the style rules, I'll agree to banish it!
>
> It comes from reading code: first recognize the
> control flow, which is fortunately easy now, then
> get the assignments. Assignments buried in other
> expressions make this harder.
> As for:
> while ((curLM = getChildLM()) != null) {
> well, this avoids writing the assignment twice.
> Nevertheless, if it's an iteration, why not use
> a more iterator like pattern:
> while (hasNextLM()) {
> curLM = nextLM();
> (Unfortunately, the sample code before this represents
> *not* a proper iterator pattern, which I actually find
> quite misleading).
There are exceptions for most rules and I think that Karen's example
shows where applying the exceptional case is clearer. The point is to be
able to recognize when the exceptions occur and apply them when they
increase the clarity of the code. Remember the point of these sorts of
standards is that: to increase the clarity of the code.
> From my experience, rules demanding to encode the scope
> of a variable in it's name are doomed for the same reason
> hungarian notation is:
> 1. You will have enough people hacking around in the code
> who don't like it or don't care or simply feel in a
> hurry.
> 2. It happens that a variable is moved from one scope to
> another. You can bet that if the variable is referenced
> more than twice, it wont be renamed. While this is
> certainly much rarer than people generally assume,
> it is probably the reason *why* people don't like
> rules for encoding scope or type in names. It feels
> like a severe restriction.
Yes but tools like checkstyle elevate some of this by warning people of
the inconsistencies.
Part of the aim of any open source project should be to make the code as
accessible as possible to potential users and contributors. One of the
key aspects to that is trying to keep the code presentation consistent
and clear.
checkstyle and the ilk make monitoring consistency trivial and the
arguments that consistency wont be achieved because someone wont do it
less effective.
IMHO (and I've benn told it doesn't always come over as humble :)),
consistent code standards are as important to the long term success of a
project as unit tests.
-k.
--
If you don't test then your code is only a collection of bugs which
apparently behave like a working program.
Website: http://radio.weblogs.com/0111457/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: Style issues.
> -Original Message- > From: Peter B. West [mailto:[EMAIL PROTECTED]] > Sent: August 20, 2002 9:51 PM > To: [EMAIL PROTECTED] > Subject: Re: Style issues. [ SNIP ] > > The only encoding rule I'd realy like to have: > > Don't mix underscores with camelCase. > > Beside looking *really* ugly, it screws up Emacs' dynamic > > identifier completion, and I'd rather like to do > > something for FOP than fixing this. > > It comes down to "ugliness", doesn't it? "camelCase" is nice. I > haven't heard it before, and I agree with your admonition. This one is weird. :-) I have associated camelCase with Java, and expect to see it. I dislike Microsoft naming conventions for VB and C# (I guess you could call it capitalized camelCase, or Camelcase), without being able to say why. And for C I cannot abide anything but underscore separators and all lowercase. I think it is all a mater of habit. I may be a person who is ill-qualified to comment on variable names. I like assembler and machine code, and I never had a problem with the variable naming conventions for FORTRAN (I, J, K, L, M, N are INTEGER, etc). :-) Of course, I started with punched cards so I was overjoyed to actually have variables...sounds like a Monty Python skit (_you_ had _variables_?! I walked 10 miles both ways to school, uphill, in deep snow, and I had to hardcode the machine addresses on paper tape..._You_ had paper tape?! I lived in a culvert, didn't go to school, and flipped switches on vacuum tubes to set the program). Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Style issues.
J.Pietschmann wrote:
> Karen Lease wrote:
>
>>> if ((bp = getNextBreakPoss(childLC, null)) != null) {
>>
>> Probably comes from long years of writing C and C++ and avoiding extra
>> lines of code. Must be taste since I don't find it that bad, but if we
>> all vote it out in the style rules, I'll agree to banish it!
>
>
> It comes from reading code: first recognize the
> control flow, which is fortunately easy now, then
> get the assignments. Assignments buried in other
> expressions make this harder.
> As for:
>while ((curLM = getChildLM()) != null) {
> well, this avoids writing the assignment twice.
> Nevertheless, if it's an iteration, why not use
> a more iterator like pattern:
>while (hasNextLM()) {
>curLM = nextLM();
> (Unfortunately, the sample code before this represents
> *not* a proper iterator pattern, which I actually find
> quite misleading).
It comes from reading code. If you have been writing C code for years,
the first idiom is actually easier to follow. I suppose you could say,
if you needed such a crutch, that it was a pattern.
>
>>> 6. ...hungarian notation.
>>
>> Like most everyone else that's responded, I say, let's just pick a
>> rule that makes it clear what are member or static variables and which
>> are local and stick to it. Personally I tend to prefer m_xxx to
>> this.xxx, with or without hungarian.
>
>
> From my experience, rules demanding to encode the scope
> of a variable in it's name are doomed for the same reason
> hungarian notation is:
> 1. You will have enough people hacking around in the code
>who don't like it or don't care or simply feel in a
>hurry.
> 2. It happens that a variable is moved from one scope to
>another. You can bet that if the variable is referenced
>more than twice, it wont be renamed. While this is
>certainly much rarer than people generally assume,
>it is probably the reason *why* people don't like
>rules for encoding scope or type in names. It feels
>like a severe restriction.
>
> Let's apply common sense:
> 1 If you introduce a variable, use the smallest scope which
> will do the job.
> 2 Don't reuse the same variable for different things.
> 3 If the scope is reasonably small, declare a local
> variable just before it is used. Otherwise declare it
> at the beginning of the block which contains the scope.
> 4 Declare instance variables at the beginning of the class.
> 5 Declare class variables before instance variables.
> 6 Don't litter variable declaration blocks with unnecessary
> comments and empty lines. Use longer names if possible.
> Comment only blocks with block comments. Comment
> individual declarations with endline comments only.
> 7 Avoid both large functions as well as lots of small
> private functions which are used only once or perhaps
> twice. This does not mean functions of 300 lines length
> should not occur, it means such functions should not occur
> too often, and declarations for local variables should be
> placed wisely.
>
> Interestingly, there is no need to enforce the rules 3-6.
> Moving a bunch of lines is much easier than to rename a
> variable (because you don't have spurious matches to
> check), so someone *will* find variable declarations
> buried at arbitrary places ugly and move them where they
> usually look for variable declarations. Of course it is
> an advantage if there are already examples there...
>
> The result of such simple rules: If you look at some code,
> and there is an unqualified variable, center it in the
> editor window and either you see the declaration already,
> or you have to scroll up one or two screens to get near the
> function header, or you have to search near the beginning
> of the file (you'll probably know after a few tries which
> files have huge comment blocks at the beginning).
Let's call them guidelines, especially as they don't need to be
enforced, and more especially as they cannot be. 1 and 2 are like the
others, in that they tend to appeal to the aesthetic sense, and code
that is aesthetically appealing will usually be found to work better.
This is not a rule. It's not even a guideline.
I can't imagine that anyone, as he codes, ticks off a checklist of style
rules. It's a matter of habit and example. One reads suggestions like
Joerg's above and decides that, yes, that's a good idea, and it becomes
part of one's personal armoury of techniques.
But they remain, I hope always, personal. I _want_ to be able to pick
up code and say, ah, that's Keiron's, that's Karen's, without having to
look for an @author. Back in the mists of time, I did a few subjects in
CS at UofQueensland. When I picked up a Fortran assignment from the
lecturer, he commented that I'd been programming for some time. I had.
"You have a certain style." My experience was recognisable in my
code. The maker's mark is not the signature
Re: Line breaks around dashes
J.Pietschmann wrote: > TR14 needs a table for certain character properties be present, > which can be derived from the official database. We probably > need such a table for other purposes too, for example writing > direction and word separation. I fear an implementation which > is not too heavyweight could be tricky, however, there is a > report from the Unicode consortium which covers exactly this > topic, I just hadn't had time to read it yet. Some form of character properties database is essential. Not only line breaking but also bidi processing depend upon it. In general, the only knowledge we can assume about the characteristics of the text we are processing is what is contained in the database. Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ "Lord, to whom shall we go?" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Line breaks around dashes
On Tue, 20 Aug 2002, J.Pietschmann wrote: > I fiddled a bit with page number initialisation. Could > you post a small example which demonstrates the effect > you noticed? Use to generate > pages to keep it short. Attached. It looks like every page-sequence starts over from zero -- except the very first one, which starts from one. (You would have figured that out right away, but I had to say something more than just "attached.") j --- "Users complain that they receive too much spam, while spammers protest messages are legal." -InfoWorld "You do not have to do everything disagreeable that you have a right to do." -Judith Martin (Miss Manners) http://www.w3.org/1999/XSL/Format";> This is the first page, generated number: This is the second page, generated number: This is the third page, generated number: Static content Page four, generated: Page five, generated: Page six, generated: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Line breaks around dashes
Jessica Perry Hekman wrote: > Is broken on that branch? It was working fine in 0.20.4. > However, in the version I checked out from cvs, calling it in some > page-sequences returns the number "0", and then when eventually it does > start working, it starts counting from "1," even though there were about 8 > rendered pages before that one. I fiddled a bit with page number initialisation. Could you post a small example which demonstrates the effect you noticed? Use to generate pages to keep it short. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Line breaks around dashes
On Mon, 19 Aug 2002, J.Pietschmann wrote: > HEAD doesn't work, check out fop-0_20_2-maintain. Done. Is broken on that branch? It was working fine in 0.20.4. However, in the version I checked out from cvs, calling it in some page-sequences returns the number "0", and then when eventually it does start working, it starts counting from "1," even though there were about 8 rendered pages before that one. j --- "Users complain that they receive too much spam, while spammers protest messages are legal." -InfoWorld "You do not have to do everything disagreeable that you have a right to do." -Judith Martin (Miss Manners) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tasks - layout
Arved, That would be good. I haven't looked at it for a month or so, but I had (as usual) some questions about various statements in the XSL-FO spec concerning the interpretation of the various properties. Perhaps we could go over those issues at some point. Karen Arved Sandstrom wrote: >>-Original Message- >>From: Karen Lease [mailto:[EMAIL PROTECTED]] >>Sent: August 19, 2002 6:58 PM >>To: [EMAIL PROTECTED] >>Subject: Re: Tasks - layout >> >> > [ SNIP ] > >>With regard to the line-height calculations, is anybody in the group >>interested in getting into the gory details of the baseline stuff for >>different scripts? I spent some time poring over the spec and trying to >>get a handle on this, but maybe it's too much detail for now. On the >>other hand, I'd really like to make sure that this version of FOP >>handles that stuff correctly as well as being able to do the various >>kinds of line-stacking strategies defined by the XSL-FO spec. >> > > I am definitely interested. I have put some thought into these things > already. Granted, when I implement it'll be a different codebase but I am > happy to work out the details on this list. > > Arved > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: layout questions
olivier wrote: > In fact I encounter troubles while rendering BMPs with FOP (PDF output). > They seem to be automatically downsampled (their quality is really bad), or > something like that. Is there anybody that could give me a way to search ? Unless you specify height and/or width on the fo:external-graphic element, the image is rendered at a resolution of 72dpi. This will look bad on most printers. I'm not aware of any resampling of any image, but you can easily check for yourself in the FOP source. > Another question of mine could be : Is there a chance for the keep.* > properties to be implemented soon ? If it is, is there a way I could (try > to) help. keep-with-* already works on table rows. You can take advantage of this by putting stuff you want to have kept together in a blind table. The redesign where keeps are expected to be fully implemented will still take a while. > Finally, i've tried to import some BMPs as and it was > always giving me an ArrayIndexOutOfBounds Exception. > These BMPs where edited with PhotoShop. If I pre-edit them with windows's > paint, there's no problem at all. Does anyone know something about this ? This sounds like a known bug. Check bugzilla: http://nagoya.apache.org/bugzilla/ whether there is already an open bug, if not, opoen one and append a *small* BMP which causes such a problem. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: ArrayIndexOutOfBound Exception while dynamic row generation
Please don't send HTML mails to the list. Amerin Szulr wrote: > I'm trying to generate dynamic rows, i' can able to get results for a > row. Once my XML values greater than that of the columns, , i'm getting > ArrayIndexOutOfBoundException I hope I guess right that you want to have rows with more cells than there are table columns. FOP can't deal with this, each row must have at most as much cells as there are columns declared at the beginning of the table. Ask on the XSL list for tricks how to achive this http://www.mulberrytech.com/xsl/xsl-list/ You could for example try ... J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: fo:float
Don Willems wrote: > I am working on a document that includes (large) images. These images > should be put at the top or at the bottom of a page. As I understand it > the xsl:fo specification tells me to use fo:float, but that is not > implemented yet in fop. > > So my question is. is anybody working on fo:float and if so when can we > expect it? > There will be a support for floats in the redesigned version of FOP. It is, however, not quite clear yet when it will be available. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Line breaks around dashes
Karen Lease wrote: > That's a good question. As far as I've seen there's nothing official in > the specification, so it's up to each implementation to handle this. I > believe it falls in the category of things which could be defined by the > "user agent" idea in FOP and then used by the line-breaking algorithm. > In the redesign branch of FOP, the line-breaking code assumes it has a > list of legal line-break characters; clearly this needs to depend on the > script, which isn't yet the case. There seems to be a general consensus that a FO processor has to be an Unicode compliant application, even though the spec appears to carefully avoid to make this explicit. This would mean implementing the Unicode TR14 line breaking algorithm which is basically script independent (it inherently handles *all* scripts), apart from cases which are explicitely left to "a higher application layer" (which I'd recommend to read as: "let the user insert soft hyphens and zero width spaces if he wants to have breaks"). TR14 needs a table for certain character properties be present, which can be derived from the official database. We probably need such a table for other purposes too, for example writing direction and word separation. I fear an implementation which is not too heavyweight could be tricky, however, there is a report from the Unicode consortium which covers exactly this topic, I just hadn't had time to read it yet. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Style issues.
Karen Lease wrote:
>> if ((bp = getNextBreakPoss(childLC, null)) != null) {
> Probably comes from long years of writing C and C++ and avoiding extra
> lines of code. Must be taste since I don't find it that bad, but if we
> all vote it out in the style rules, I'll agree to banish it!
It comes from reading code: first recognize the
control flow, which is fortunately easy now, then
get the assignments. Assignments buried in other
expressions make this harder.
As for:
while ((curLM = getChildLM()) != null) {
well, this avoids writing the assignment twice.
Nevertheless, if it's an iteration, why not use
a more iterator like pattern:
while (hasNextLM()) {
curLM = nextLM();
(Unfortunately, the sample code before this represents
*not* a proper iterator pattern, which I actually find
quite misleading).
>> 3. Exceptions
> Agreed, it would be better to recheck super.hasNext() rather than
> letting it throw the exception. However, you'll note that the exception
> is only propagated from this method in the case where it's hasNext()
> returns false, which is the normal behavior for an Iterator.
It's not the case where the exception is rethrown, it's
the regular case.
>> 6. ...hungarian notation.
> Like most everyone else that's responded, I say, let's just pick a rule
> that makes it clear what are member or static variables and which are
> local and stick to it. Personally I tend to prefer m_xxx to this.xxx,
> with or without hungarian.
From my experience, rules demanding to encode the scope
of a variable in it's name are doomed for the same reason
hungarian notation is:
1. You will have enough people hacking around in the code
who don't like it or don't care or simply feel in a
hurry.
2. It happens that a variable is moved from one scope to
another. You can bet that if the variable is referenced
more than twice, it wont be renamed. While this is
certainly much rarer than people generally assume,
it is probably the reason *why* people don't like
rules for encoding scope or type in names. It feels
like a severe restriction.
Let's apply common sense:
1 If you introduce a variable, use the smallest scope which
will do the job.
2 Don't reuse the same variable for different things.
3 If the scope is reasonably small, declare a local
variable just before it is used. Otherwise declare it
at the beginning of the block which contains the scope.
4 Declare instance variables at the beginning of the class.
5 Declare class variables before instance variables.
6 Don't litter variable declaration blocks with unnecessary
comments and empty lines. Use longer names if possible.
Comment only blocks with block comments. Comment
individual declarations with endline comments only.
7 Avoid both large functions as well as lots of small
private functions which are used only once or perhaps
twice. This does not mean functions of 300 lines length
should not occur, it means such functions should not occur
too often, and declarations for local variables should be
placed wisely.
Interestingly, there is no need to enforce the rules 3-6.
Moving a bunch of lines is much easier than to rename a
variable (because you don't have spurious matches to
check), so someone *will* find variable declarations
buried at arbitrary places ugly and move them where they
usually look for variable declarations. Of course it is
an advantage if there are already examples there...
The result of such simple rules: If you look at some code,
and there is an unqualified variable, center it in the
editor window and either you see the declaration already,
or you have to scroll up one or two screens to get near the
function header, or you have to search near the beginning
of the file (you'll probably know after a few tries which
files have huge comment blocks at the beginning).
The only encoding rule I'd realy like to have:
Don't mix underscores with camelCase.
Beside looking *really* ugly, it screws up Emacs' dynamic
identifier completion, and I'd rather like to do
something for FOP than fixing this.
J.Pietschmann
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
layout questions
hi all,I thought about those questions because I need to use FOP the best way i can ( for sure ;) ) but also because, as a visual renderer, there is great chance for people to really need these importants features to be implemented or optimised in FOP.First of all, I'd like to know a bit more about FOP's BMPRenderer.In fact I encounter troubles while rendering BMPs with FOP (PDF output).They seem to be automatically downsampled (their quality is really bad), or something like that. Is there anybody that could give me a way to search ?Another question of mine could be : Is there a chance for the keep.* properties to be implemented soon ? If it is, is there a way I could (try to) help.Finally, i've tried to import some BMPs as and it was always giving me an ArrayIndexOutOfBounds Exception.These BMPs where edited with PhotoShop. If I pre-edit them with windows's paint, there's no problem at all. Does anyone know something about this ?Thanks in advance.
AW: Renderer for RTF & AFP
Hi Betrand, I've tried out jfor (for conversion to rtf out of fo). It's working fine for simple documents, as the examples are. Should it also work for more complicated documents with such things as headers, footers, pagenumbers, indexes and tables of contents with the correct pagenumbers? I've tried jfor out with such a more complicated fo, which is working well with generating PDF, but is maybe not implemented in jfor yet? Headers, pagenumbers, table of contents, pagebreaking a.s.o are not working, but graphics, bold (und kursiv usw.), normal text etc. are. rgrds Kurt -Ursprüngliche Nachricht- Von: Bertrand Delacretaz [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 2. August 2002 17:44 An: [EMAIL PROTECTED]; Kurt Spescha; '[EMAIL PROTECTED]' Betreff: Re: Renderer for RTF & AFP On Friday 02 August 2002 17:14, Kurt Spescha wrote: > . . .RTF has been > announced as beeing integrated soon. How soon? We're expecting a contribution in this area in a week or two, but this will go into the redesign code base first, so it will take some time before actually being released. In the meantime you can use jfor (www.jfor.org) to generate RTF from XSL-FO. Not complete but usable with some workarounds depending on the desired output. -- Bertrand Delacrétaz (codeconsult.ch, jfor.org) buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding. disclaimer: eternity is very long. mostly towards the end. get ready. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
ArrayIndexOutOfBound Exception while dynamic row generation
Hi, I'm trying to generate dynamic rows, i' can able to get results for a row. Once my XML values greater than that of the columns, , i'm getting ArrayIndexOutOfBoundException Any Help ? title 1 title 2 title 3 title 4 Error :- C:\FOP\fop-0.20.3>java -cp build\fop.jar;lib\batik.jar;lib\xalan-2.0.0.jar;lib\xerces-1.2.3.jar;lib\avalon-framework-4.0.jar;lib\logkit-1.0.jar;lib\jimi-1.0.jar org.apache.fop.apps.Fop -xsl test.xsl -xml test.xml -pdf test.pdf[INFO]: FOP 0.20.3[INFO]: building formatting object tree[INFO]: [1][WARN]: table-layout=auto is not supported, using fixed![INFO]: [2][ERROR]: java.lang.ArrayIndexOutOfBoundsException thans in advance.Do You Yahoo!? HotJobs, a Yahoo! service - Search Thousands of New Jobs
fo:float
Hi, I am working on a document that includes (large) images. These images should be put at the top or at the bottom of a page. As I understand it the xsl:fo specification tells me to use fo:float, but that is not implemented yet in fop. So my question is. is anybody working on fo:float and if so when can we expect it? If not I'll start working on it, but I'll probably need some help as I have only experience with fop as a user. Bye, Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/contrib/plan/src/org/apache/fop/plan SimplePlanDrawer.java
keiron 2002/08/20 01:09:00
Modified:contrib/mathml build.sh
contrib/mathml/src/org/apache/fop/mathml MathMLElement.java
contrib/plan build.sh
contrib/plan/src/org/apache/fop/plan SimplePlanDrawer.java
Log:
updated classpath, fixed some small errors
Revision ChangesPath
1.3 +1 -1 xml-fop/contrib/mathml/build.sh
Index: build.sh
===
RCS file: /home/cvs/xml-fop/contrib/mathml/build.sh,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- build.sh 7 Aug 2002 12:51:56 - 1.2
+++ build.sh 20 Aug 2002 08:08:59 - 1.3
@@ -12,7 +12,7 @@
exit 1
fi
LIBDIR=../../lib
-LOCALCLASSPATH=$JAVA_HOME/lib/tools.jar:$JAVA_HOME/lib/classes.zip:$LIBDIR/ant.jar:$LIBDIR/batik.jar:$LIBDIR/buildtools.jar:$LIBDIR/xerces-1.4.3.jar:$LIBDIR/xalan-2.2D11.jar:../../build/fop.jar:$LIBDIR/avalon-framework-cvs-20020806.jar:lib/jeuclid.jar
+LOCALCLASSPATH=$JAVA_HOME/lib/tools.jar:$JAVA_HOME/lib/classes.zip:$LIBDIR/ant.jar:$LIBDIR/batik.jar:$LIBDIR/buildtools.jar:$LIBDIR/xercesImpl-2.0.1.jar:$LIBDIR/xalan-2.2D11.jar:$LIBDIR/xml-apis.jar:../../build/fop.jar:$LIBDIR/avalon-framework-cvs-20020806.jar:lib/jeuclid.jar
ANT_HOME=$LIBDIR
echo
1.2 +2 -2
xml-fop/contrib/mathml/src/org/apache/fop/mathml/MathMLElement.java
Index: MathMLElement.java
===
RCS file:
/home/cvs/xml-fop/contrib/mathml/src/org/apache/fop/mathml/MathMLElement.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- MathMLElement.java23 Apr 2002 10:26:46 - 1.1
+++ MathMLElement.java20 Aug 2002 08:08:59 - 1.2
@@ -63,7 +63,7 @@
doc = svgDoc;
}
} catch (Throwable t) {
-log.error("Could not convert MathML to SVG", t);
+userAgent.getLogger().error("Could not convert MathML to SVG", t);
width = 0;
height = 0;
}
1.5 +1 -1 xml-fop/contrib/plan/build.sh
Index: build.sh
===
RCS file: /home/cvs/xml-fop/contrib/plan/build.sh,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- build.sh 7 Aug 2002 12:51:56 - 1.4
+++ build.sh 20 Aug 2002 08:08:59 - 1.5
@@ -12,7 +12,7 @@
exit 1
fi
LIBDIR=../../lib
-LOCALCLASSPATH=$JAVA_HOME/lib/tools.jar:$JAVA_HOME/lib/classes.zip:$LIBDIR/ant.jar:$LIBDIR/batik.jar:$LIBDIR/buildtools.jar:$LIBDIR/xerces-1.4.3.jar:$LIBDIR/xalan-2.2D11.jar:../../build/fop.jar:$LIBDIR/avalon-framework-cvs-20020806.jar
+LOCALCLASSPATH=$JAVA_HOME/lib/tools.jar:$JAVA_HOME/lib/classes.zip:$LIBDIR/ant.jar:$LIBDIR/batik.jar:$LIBDIR/buildtools.jar:$LIBDIR/xercesImpl-2.0.1.jar:$LIBDIR/xalan-2.2D11.jar:$LIBDIR/xml-apis.jar:../../build/fop.jar:$LIBDIR/avalon-framework-cvs-20020806.jar
ANT_HOME=$LIBDIR
echo
1.3 +2 -2
xml-fop/contrib/plan/src/org/apache/fop/plan/SimplePlanDrawer.java
Index: SimplePlanDrawer.java
===
RCS file:
/home/cvs/xml-fop/contrib/plan/src/org/apache/fop/plan/SimplePlanDrawer.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- SimplePlanDrawer.java 21 Mar 2002 10:02:13 - 1.2
+++ SimplePlanDrawer.java 20 Aug 2002 08:09:00 - 1.3
@@ -275,7 +275,7 @@
line = SVGUtilities.createLine(doc,
(float)(200 + (currentDays + 0.5) * 300 /
35), graphTop,
(float)(200 + (currentDays + 0.5) * 300 /
35), height);
-line.setAttributeNS(null, "style",
"fill:none;stroke:rgb(200,50,50);stroke-dasharray:5 5");
+line.setAttributeNS(null, "style",
"fill:none;stroke:rgb(200,50,50);stroke-dasharray:5,5");
svgRoot.appendChild(line);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tasks - layout
On Mon, 2002-08-19 at 23:13, J.Pietschmann wrote: > Keiron Liddle wrote: > > - Implement table layout > > The table layout will use the same technique as the block layout. It > > will locate suitable breaks between rows or inside rows until table > > finished or end of bpd reached. > > Actually, what *are* valid breaks within a table apart from breaks > between two rows with no cell spanning both? > > Some interesting situations: > > +-++ > |block|block 1 | > | |block 2 | > +-++ > Break possibility after block 1 if > BPD(block) +-++ > |block|block 1 | > +-++ > --- > +-++ > | |block 2 | > +-++ For this case I would say it is a valid break. Because table row can have keep together which only makes sense if the row can be split when there is no keep. > +-++ > |block block block|block 1 | > |block block block++ > |block block |block 2 | > +-++ > Break possibility after row one, despite that > the cell with block 1 would have to get some > space after the block, i.e. > +-++ > |block block block|block 1 | > |block block block|| > |block block ++ > --- > | ++ > | |block 2 | > +-++ It should be possible to get a break inside a cell but I don't know how the break should be found across the row. What happens if there is a page-break inside a cell. Do other cells go to the end of the page or to their limit? or should the break be at the same position across the row. Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: cvs commit: xml-fop/src/org/apache/fop/render/pdfPDFRenderer.java
On Mon, 2002-08-19 at 22:34, J.Pietschmann wrote:
> [EMAIL PROTECTED] wrote:
> >protected void renderRegion(RegionReference region) {
> ...
> > +currentFontName = "";
>
> Wouldn't it be better to do this each time after
> writing a BT to the PDF output? (In startVParea(),
> renderViewport() and renderLeader()).
Only of the BT is the first in a graphic state with no inherited font.
The PDFState could handle this but it is low on the list...
> J.Pietschmann
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Tasks - layout
On Mon, 2002-08-19 at 22:58, J.Pietschmann wrote: > Keiron Liddle wrote: > > - Add markers to page when areas added > Is this really a good idea? Markers may be referenced > long after they have been defined, tying them to the > Page object would require keeping the pages in memory > (see 0.20.5cvs: forward page references are *required* > to force keeping pages in memory so that markers can > be retrieved with document scope). I thought the markers only apply to the current page but I haven't really looked into it. If it does apply to pagesequence/document then it should be on the page viewport like the id references, so that the page can be removed leaving relevent information for use later. There may be other places to keep the markers but the area tree might be easier to keep track of. > I thought about adding a running number for the page > sequence and for the page within it's page sequence > as well as the necessary information to make retrieving > markers within a page work properly to the marker itself > and store them in an Array list, with the current page > perhaps storing the array index of the first marker of > this page to speed up some retrieval modes. Page numbers would be good. I think that you only need at most four markers of a particular class per page, so if it is a dictionary type case it doesn't need all the markers in the middle of the page with the same class. > J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
