Hi Rhett,
On Wed, 2002-11-20 at 16:44, Rhett Aultman wrote:
I may be green, but I did spot some of this a couple weeks ago, and it went mostly
unnoticed. While writing this email, I downloaded another CVS snapshot and the
super-simple test document from bug #8778, which is probably the
pbwest 2002/11/21 00:11:50
Modified:src/org/apache/fop/fo/pagination Tag: FOP_0-20-0_Alt-Design
FoLayoutMasterSet.java
Log:
Add processing of simplepage-masters into PageSequenceMasters.
Revision ChangesPath
No revision
pbwest 2002/11/21 00:14:42
Modified:src/org/apache/fop/fo/pagination Tag: FOP_0-20-0_Alt-Design
PageSequenceMaster.java
Log:
Add constructor to generate PageSequenceMaster from FoSimplePageMaster.
Revision ChangesPath
No
pbwest 2002/11/21 00:22:16
Modified:src/org/apache/fop/fo/properties Tag: FOP_0-20-0_Alt-Design
Property.java
Log:
Added INTEGER and ENUM to refineParsing().
Revision ChangesPath
No revision
No revision
pbwest 2002/11/21 00:23:13
Modified:src/org/apache/fop/fo/properties Tag: FOP_0-20-0_Alt-Design
BorderStyle.java
Log:
Extend BorderCommonStyle.
Revision ChangesPath
No revision
No revision
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7400.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Peter B. West wrote:
[...]
STATUS:
The XML pull buffering has been working for some considerable time. I
have simply been extending the get/expect methods on top of the simpler
methods as I have found a requirement for them in building the FO tree.
In cases where the DTD is well known and
In order to resolve the display ... problem, I embed a truetype font
by setting up userconfig.xml and call new Option in program. So, the PDF
file created by FOP can show the foreign words correctly. But at this time,
there are some unbreak text block displaying out of the body region.
pbwest 2002/11/21 02:01:47
Modified:src/org/apache/fop/fo/flow Tag: FOP_0-20-0_Alt-Design
FoBasicLink.java
Log:
Subtree processing.
Revision ChangesPath
No revision
No revision
1.1.2.7 +2 -2
pbwest 2002/11/21 02:29:59
Modified:src/org/apache/fop/fo/flow Tag: FOP_0-20-0_Alt-Design
FoBasicLink.java
Log:
Adjusting for rcs errors.
Revision ChangesPath
No revision
No revision
1.1.2.8
pbwest 2002/11/21 02:45:08
Modified:src/org/apache/fop/fo/flow Tag: FOP_0-20-0_Alt-Design
FoBlockContainer.java
Log:
Adjust for RCS errors.
Revision ChangesPath
No revision
No revision
1.1.2.8
pbwest 2002/11/21 02:49:11
Modified:src/org/apache/fop/fo/flow Tag: FOP_0-20-0_Alt-Design
FoBlock.java
Log:
Adjust for RCS errors.
Revision ChangesPath
No revision
No revision
1.1.2.8 +2 -2
pbwest 2002/11/21 02:53:08
Modified:src/org/apache/fop/fo/flow Tag: FOP_0-20-0_Alt-Design
FoFloat.java
Log:
Adjust for RSC errors.
Revision ChangesPath
No revision
No revision
1.1.2.7 +2 -2
pbwest 2002/11/21 02:55:48
Modified:src/org/apache/fop/fo/flow Tag: FOP_0-20-0_Alt-Design
FoFootnoteBody.java
Log:
Adjust for RCS errors.
Revision ChangesPath
No revision
No revision
1.1.2.7
Peter B. West wrote:
quote
...
Echoing sentiments recently expressed in this publication, Clark said
that SAX, though efficient, was very hard to use, and that DOM had
obvious limitations due to the requirement that the document being
processed be in memory. He suggested that what was needed
On Thu, 2002-11-21 at 12:43, Victor Mote wrote:
To conclude, if I were designing this system from scratch, based on what I
know right now, I would:
1. Use DOM for both the fo tree the area tree.
I don't know whether I would call it a DOM but the area tree is an
independant data structure that
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7241.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7241.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Peter B. West wrote:
I like pull parsing model in general, but how do you manage with not
such strict content model as fo:root have, e.g. fo:block with
(#PCDATA|%inline;|%block;)* ?
How about:
FoXMLEvent ev = expectStartElement
(FObjectSets.normalPcdataBlockInlineSet,
Responses below.
-Original Message-
From: Keiron Liddle [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 21, 2002 3:08 AM
To: FOP
Subject: RE: Getting breaks: revisited
Hi Rhett,
On Wed, 2002-11-20 at 16:44, Rhett Aultman wrote:
I may be green, but I did spot some of this a couple
Yueshu Jesse wrote:
In order to resolve the display ... problem, I embed a truetype
font by setting up userconfig.xml and call new Option in program. So,
the PDF file created by FOP can show the foreign words correctly. But at
this time, there are some unbreak text block displaying out of
Hi,
I'm using fop 0.20.4 with jdk 1.4 and would like to get some background
information about how fop embedds unicode character from a true type font which
is not one of the 14 PDF Standard Fonts. I used Arial Unicode Ms.ttf to
embed some asien characters into an pdf document. Based on the
Victor Mote wrote:
The issue with SAX as I see it, is that because it is one-way, and our
processing is not (I think the standard calls it non-linear), we
presumably have to essentially build our own DOM-ish (random access) things
in order to get the job done.
I think we should separate fo tree
The polygons come from staroffice 6.0 export to svg, so I have to live with
them.
Are there some planes to build a new release, containing the right
implementation in cvs?
Regards, Carsten
-
To unsubscribe, e-mail: [EMAIL
On Thu, 2002-11-21 at 14:20, Rhett Aultman wrote:
IIRC, in my 8778 experiment, the break being offered was never null. The best
break is always being offered, but the best break is at the beginning of the
offending block. Either way, this resolves only the most trivial of the examples
Oleg,
...
Oleg Tkachenko wrote:
Peter B. West wrote:
taking a very isolated path. My motivation can be summed up in the
slogan SAX SUX. I couldn't understand why anyone would persist with
it for any complex tasks, e.g. FOP.
Actually I cannot say I fully agree with this, because I don't
Oleg Tkachenko wrote:
Peter B. West wrote:
I like pull parsing model in general, but how do you manage with not
such strict content model as fo:root have, e.g. fo:block with
(#PCDATA|%inline;|%block;)* ?
How about:
FoXMLEvent ev = expectStartElement
Responses below.
-Original Message-
From: Keiron Liddle [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 21, 2002 9:11 AM
To: FOP
Subject: RE: Getting breaks: revisited
On Thu, 2002-11-21 at 14:20, Rhett Aultman wrote:
No, in the design the best break cannot be before the block,
On Thu, 2002-11-21 at 16:03, Rhett Aultman wrote:
When you say in the design, do you mean that this is expected behavior as it is
now or as it should be at some point in the future?
That's the point of the original message, currently it doesn't do it
quite right. I am looking to adjust it to do
I'm stumbling over code blocks every now and then that could/should be
reused or even used from a common library. Examples of that are stream
copying code, little/big endian conversions etc. This is mostly little
stuff but these things wouldn't need to be in our codebase. Sometimes
there's code
On 20.11.2002 18:05:33 Bertrand Delacretaz wrote:
I voted -1 on most TBD stuff, braces and spaces are not really important IMHO
and I think it's good that the style guide stays as small as possible.
Also my opinion, though I think some good advice and best practices are
not bad. We've had
Hello!
btw, I have a q about avalon's pattern:
while( myListIterator.hasNext() )
{
final String myString = (String)myListIterator.next();
}
How do you think, is this final specifier only a style oriented or it have
some performance benefit also?
--
Oleg Tkachenko
eXperanto team
Multiconn
On Thursday 21 November 2002 17:16, Jeremias Maerki wrote:
. . .
The MUST part is very small and establishes some hard rules. I'll try to
do the final layout in XML in a way that takes this into consideration.
ok, cool!
. . .
By the way, due to common desire I added a few lines on exception
On Thursday 21 November 2002 17:31, Oleg Tkachenko wrote:
. . .
final String myString = (String)myListIterator.next();
. . .
How do you think, is this final specifier only a style oriented or it have
some performance benefit also?
I don't know about performance, but I use it all the time
It's my understanding that, for certain object types, the compiler can use final
designation as a flag for further optimizations and so it actually might be a wise
idea to do. If nothing else, I remember reading an interview with James Gosling on
object mutability, a compiler optimization
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10287.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11838.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11614.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11614.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
I am using FOP embedded in a Servlet. Users trigger the servlet by clicking
a button on a web page. The servlet then takes the response and performs a
transformation and renders to pdf. The browser pops up a new window and
displays the pdf output. 1% or so of my user population cannot get the
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4695.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9880.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14419.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Keiron Liddle wrote:
On Thu, 2002-11-21 at 12:43, Victor Mote wrote:
To conclude, if I were designing this system from scratch,
based on what I
know right now, I would:
1. Use DOM for both the fo tree the area tree.
I don't know whether I would call it a DOM but the area tree is an
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11902.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Oleg Tkachenko wrote:
I think we should separate fo tree itself from the process of its
building. fo
tree structure is required and I agree with Keiron - it's not a
DOM, it's just
tree representation and I cherish the idea to make it an
effectively small
structure like saxon's internal
Markus (Schaeffler?) wrote:
like the whole codepage in which the charater is in? Or which
information are
exactly embedded into the pdf file? Can I rely on the assumption that the
pdf file with the embedded font will be displayed correctly
independingly on
the
operating system and the
Yes, dump that directory. That's redundancy. We just have to make sure,
that the documentation points the right way, too.
On 21.11.2002 20:41:21 Oleg Tkachenko wrote:
FOP sample servlets are now at contrib/servlet directory and look fine,
but docs/examples/embedding still contains kind of
klease 2002/11/21 13:58:49
Modified:src/org/apache/fop/fonts Tag: fop-0_20_2-maintain
TTFSubSetFile.java
Log:
Correct ordering of loca table in embedded true type fonts
Revision ChangesPath
No revision
No
Hello!
I'm about to fix bug #10158 and I wonder, why in FOP default page width
is 8in although spec recommends 8.26in[1]. Well, actually in absence of
User Agent page width is implementation-defined, so we can leave 8in
happily (actually XEP also uses 8x11in defaults, but Antenna - 8,26x11).
Oleg Tkachenko wrote:
Hello!
I'm about to fix bug #10158 and I wonder, why in FOP default page width
is 8in although spec recommends 8.26in[1]. Well, actually in absence of
User Agent page width is implementation-defined, so we can leave 8in
happily (actually XEP also uses 8x11in defaults,
Hello, Oleg!
You wrote to [EMAIL PROTECTED] on Wed, 20 Nov 2002 18:02:59 +0200:
Just curious - why you recreate the dialog? You can use 1 instance
and to show/hide it by setVisible(boolean) method.
But you maight be right, because PreviewDialog is not designed to be
reusable and
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4348.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14419.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14319.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
pbwest 2002/11/21 16:35:31
Modified:src/org/apache/fop/fo/flow Tag: FOP_0-20-0_Alt-Design
FoCharacter.java FoExternalGraphic.java FoFlow.java
FoFootnote.java FoInitialPropertySet.java
FoInlineContainer.java
pbwest 2002/11/21 16:46:27
Modified:src/org/apache/fop/fo/flow Tag: FOP_0-20-0_Alt-Design
FoMarker.java FoMultiCase.java
FoMultiProperties.java FoMultiPropertySet.java
FoMultiSwitch.java FoMultiToggle.java
pbwest 2002/11/21 17:05:24
Modified:src/org/apache/fop/fo/flow Tag: FOP_0-20-0_Alt-Design
FoTableAndCaption.java FoTableBody.java
FoTableCaption.java FoTableCell.java
FoTableColumn.java FoTableFooter.java
pbwest 2002/11/21 18:07:04
Modified:src/org/apache/fop/fo/expr Tag: FOP_0-20-0_Alt-Design
PropertyParser.java
Log:
Correcting RCS problems.
Revision ChangesPath
No revision
No revision
1.5.2.19
pbwest 2002/11/21 18:17:22
Modified:src/org/apache/fop/fo/declarations Tag:
FOP_0-20-0_Alt-Design FoColorProfile.java
FoDeclarations.java
Log:
REmoved numProps arg to super constructor.
DECLARATIONS_SET now in FONode.
Revision
pbwest 2002/11/21 18:48:35
Modified:src/org/apache/fop/fo Tag: FOP_0-20-0_Alt-Design
FObjectSets.java FObjects.java FONode.java
FOPropertySets.java FOTree.java
ShorthandPropSets.java
Log:
Fixed RCS problems.
pbwest 2002/11/21 18:54:56
Added: src/org/apache/fop/datatypes Tag: FOP_0-20-0_Alt-Design
CountryLanguageScript.java
Log:
Generated by XSL from xml-lang.xml
Revision ChangesPath
No revision
No
Hi Mike,
it's an old problem with IE.
If you do a refresh/reload in IE the pdf should appear on the screen.
But there are several solutions:
Try a file=.pdf at the end of the url
Change the source of fop. There is somewhere a close outputstream
missing, but i forgot where it
63 matches
Mail list logo
