convert tex to fop ?
Hello , I use now Latex (~1000 doc in tex) and I want using fop but : You have a software for convert tex to fop ? Fop as a compatibility with java blackdown 118v3 (I use oracle 8.1.7) ? Thank you all. PS: excuse me for my little English. Crebassa Gilles - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 12854] - The path for the font-matrix files is in unix format under windows
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=12854. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12854 The path for the font-matrix files is in unix format under windows --- Additional Comments From [EMAIL PROTECTED] 2002-09-27 11:19 --- The error is located in the class : org.apache.fop.configuration.FontInfo method getBaseDir(). I fixed the problem by removing most of the code, and only returning the baseDir without doing enything to it. This solves it. Best regards, Casper Madsen [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: character
Arved Sandstrom wrote at 26 Sep 2002 19:50:01 -0300: Tony Graham says that character should be a Unicode character, or Char. As in the actual real, encoded thing. Empirical evidence suggests that is the general understanding: grepping the XSL CR test suite shows everybody, FOP included, using literal characters. Problem being, one property with a character datatype is defined in XSLT, which actually says that it's a Char. hyphenation-separator merely says that it's a specification of a Unicode character. I guess that could be interpreted the same way. But character for the character property says _code point_. And that is an integer value. Section 5.11, Property Datatypes, trumps the individual property definitions, since Section 5.11 defines the syntax for specifying the datatypes usable in property values. It says A single Unicode character. Now, the interesting if so far theoretical case is what do you do if you want a hyphenation-separator character that you can only represent in Unicode as the combination of a base character and one or more combining marks? What if your precomposed character gets normalised to a base character and a combining mark before the XSL processor sees it? So IMO the spec is currently very vague on this. Then write to [EMAIL PROTECTED] asking for a clarification. Regards, Tony Graham XML Technology Center - Dublinmailto:[EMAIL PROTECTED] Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3x(70)19708 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 13079] New: - PDFXObject made a very bad FOPImage.close() call
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=13079.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13079
PDFXObject made a very bad FOPImage.close() call
Summary: PDFXObject made a very bad FOPImage.close() call
Product: Fop
Version: all
Platform: Other
OS/Version: Other
Status: NEW
Severity: Blocker
Priority: Other
Component: pdf renderer
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Two Threads access same global image and one of the thread kill the content
before the other thread can load the image !
org.apache.fop.pdf.PDFXObject
...
protected int output(OutputStream stream) throws IOException {
// don't know if it's the good place (other objects can have
references to it)
fopimage.close();
...
This is the absolute wrong place to close the image!
Please delete the line!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
fo wysiwig editor
Hi all. I wonder if I can get some help. I am currently using fo and fop to generate pdf documents for a large bank, and it works beautifully. We get the XML and apply a stylesheet to produce the document. However, we have a requirements that means our using should have the ability to edit the document. That means presenting an editor for the generated fo. Is there such a wysiwig editor availabe that ayone knows of ? I have done a lot of searching, but they all seem to be very poor. There is foa, but that is very complex. I just want to edit fo, not play with other custom layout documents. If this does not exists, maybe to fop community, and I include myself in that should being a project to write an editor. The other alternative is to go fo-rtf rtf- fo. But conversions are never satisfactory. Any suggestions would be greatfully received. Regards Paul. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Antwort: fo wysiwig editor
try http://www.xslfast.com Paul.Hussein@cha se.com An: [EMAIL PROTECTED] Kopie: 27.09.02 17:06 Thema: fo wysiwig editor Bitte antworten an fop-dev Hi all. I wonder if I can get some help. I am currently using fo and fop to generate pdf documents for a large bank, and it works beautifully. We get the XML and apply a stylesheet to produce the document. However, we have a requirements that means our using should have the ability to edit the document. That means presenting an editor for the generated fo. Is there such a wysiwig editor availabe that ayone knows of ? I have done a lot of searching, but they all seem to be very poor. There is foa, but that is very complex. I just want to edit fo, not play with other custom layout documents. If this does not exists, maybe to fop community, and I include myself in that should being a project to write an editor. The other alternative is to go fo-rtf rtf- fo. But conversions are never satisfactory. Any suggestions would be greatfully received. Regards Paul. - 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: RE : Antwort: fo wysiwig editor
To the best of my knowledge, FOP is a Formatting Objects processor and renderer. There isn't a subproject in this group for a WYSIWIG FO editor. It would seem we're up to our gills in work working on FOP already. I'm certain that there's a desire out there for a free, open-source WYSIWIG FO editor, though, so perhaps you'd be interested in marshalling some people together to do it. -Original Message- From: Gilles Crebassa [mailto:[EMAIL PROTECTED]] Sent: Friday, September 27, 2002 11:30 AM To: [EMAIL PROTECTED] Subject: RE : Antwort: fo wysiwig editor Fop is free but for editing U pay ? -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Envoyé : vendredi 27 septembre 2002 17:13 À : [EMAIL PROTECTED] Objet : Antwort: fo wysiwig editor try http://www.xslfast.com Paul.Hussein@cha se.com An: [EMAIL PROTECTED] Kopie: 27.09.02 17:06 Thema: fo wysiwig editor Bitte antworten an fop-dev Hi all. I wonder if I can get some help. I am currently using fo and fop to generate pdf documents for a large bank, and it works beautifully. We get the XML and apply a stylesheet to produce the document. However, we have a requirements that means our using should have the ability to edit the document. That means presenting an editor for the generated fo. Is there such a wysiwig editor availabe that ayone knows of ? I have done a lot of searching, but they all seem to be very poor. There is foa, but that is very complex. I just want to edit fo, not play with other custom layout documents. If this does not exists, maybe to fop community, and I include myself in that should being a project to write an editor. The other alternative is to go fo-rtf rtf- fo. But conversions are never satisfactory. Any suggestions would be greatfully received. Regards Paul. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - 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: character
Peter B. West wrote at 28 Sep 2002 00:39:34 +1000: ... Tony Graham wrote: ... Section 5.11, Property Datatypes, trumps the individual property definitions, since Section 5.11 defines the syntax for specifying the datatypes usable in property values. It says A single Unicode character. Ok, so it's a character. How, then, is it represented? Is it also a string (of length one), or is it just a literal (length 1), or just an NCName (length 1), or is it something else? What does it look like, and how is the parser going to handle it? A character is a character, and you should go to XML 1.0 for the definition of a character. Also, parser is ambiguous in this context as well as having no XML or XSL meaning. XML defines an XML processor, which is often called a parser for historical reasons, and the XSL Recommendation uses parse without designating a thing called a parser. ... So IMO the spec is currently very vague on this. Then write to [EMAIL PROTECTED] asking for a clarification. Nice dry wit you have Tony. That was a serious suggestion. You do get an answer eventually, even if you don't like the answer. Regards, Tony Graham XML Technology Center - Dublinmailto:[EMAIL PROTECTED] Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3x(70)19708 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Antwort: fo wysiwig editor
Paul Hussein wrote: Al I want is an editor that that works with FO only. I don't know of anything out there right now that does what you are looking for. FO is not intended to be an editable format, but rather an intermediate format. The advantage to using FO is that it can be created pretty easily (using XSLT) from semantic XML. If you don't need that advantage, but need a WYSIWIG editor and PDF output, and don't mind paying for it, I would recommend either Microsoft Word or Adobe FrameMaker. Word's limitations are well-known, and FrameMaker has two that were major for us -- lack of Unicode support, and some footnote problems. There are other page layout engines that can create PDF as well, some with XML integration -- Arbortext comes to mind, but I am much less familiar with their products. In the long run, I am hopeful that some method will be devised that will allow the FO document to be tied back to its original semantic XML document so that the semantic XML document could be reconstructed from the WYSIWIG-editable FO document (or area tree document). A user could open a document pointing to 1) the semantic XML document, and 2) the appropriate stylesheet, edit it in a WYSIWIG session, then save the underlying semantic XML and stylesheet documents. This would be the best of all worlds, but I do not even yet have a clear idea that it is feasible. I agree strongly with Rhett that there is quite a bit of work left to just get FOP's existing mission completed, but the great thing about open source is that no one can (or would want to) stop you from working on such a project if you wished. Victor Mote (mailto:[EMAIL PROTECTED]) Enterprise Outfitters (www.outfitr.com) 2025 Eddington Way Colorado Springs, Colorado 80916 Voice 719-622-0650, Fax 720-293-0044 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: character
[EMAIL PROTECTED] wrote at 27 Sep 2002 16:44:32 -0300: Out of the XML recomendation,section 2.2: A character is an atomic unit of text as specified by ISO/IEC 10646 [ISO10646]. Legal characters are tab, carriage return, line feed, and the legal graphic characters of Unicode and ISO/IEC 10646. XML 1.0 Second Edition removed graphic (which I always found confusing but which is good ISO-speak). or, more clearly: Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x1-#x10] /* any Unicode character, excluding the surrogate blocks, FFFE, and . */ That means -, #12235 , etc are characters, while '1' is not. #12235; is a character reference. '#12235' is how you talk about a character's code point, although the hexadecimal representation is usually preferable. In XSL terms, '1' is a one-character string literal, but while you could claim that it is one character, there's no XSL conversion from a string to a character, so fo:character character='1'/ should fail. Regards, Tony Graham XML Technology Center - Dublinmailto:[EMAIL PROTECTED] Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3x(70)19708 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[Fwd: Re: Regarding your comment about string on xsl-editors]
Original Message
Subject: Re: Regarding your comment about string on xsl-editors
Date: Fri, 27 Sep 2002 14:00:53 -0500
From: Paul Grosso [EMAIL PROTECTED]
To: Peter B. West [EMAIL PROTECTED]
CC: xsl-editors [EMAIL PROTECTED]
References: [EMAIL PROTECTED]
Peter,
Unfortunately, as you surmise, I doubt we would be able to make
changes such as you suggest that would make existing valid XSL
stylesheets invalid, especially for no visible benefit to the
end users.
As I indicated, the XSL FO subgroup did spend a fair amount of
time trying to weigh the various options and decided on this
compromise. Realizing that no solution is perfect, I think we
did come up with the most workable compromise. I hope you find
it acceptable.
paul
At 10:55 2002 09 27 +1000, Peter B. West wrote:
Paul,
Thank you for your response. I say this with a sense of complete
hopelessness, but would it not be better to fix XSLT than to break
XSLFO? I know there will be wailing and gnashing of teeth, and there
will probably be non-conforming implementations. However, XSLT 2.0 has
not been finalised yet, so the opportunity exists to fix it. The format
attribute value is surely a literal string, so why not express it that
way? Such a decision would flow on to XSLFO, and the previous situation
would remain correct. Current non-conforming XSLFO implementations
would be in no worse situation, and some consistency would be achieved
across the board.
While we're at it, could you possibly replace string in the data
types description with literal, and in those situations where the
NCName to string conversion may be invoked, simply allow literal|name?
In the case of font names like Times New Roman, it may be necessary
to allow something like NCNAMES. I'm sorry that is a bit vague. I
haven't thought through that particular situation (which was one of the
triggers for my original post).
Peter
Paul Grosso wrote:
Peter,
Thank you for your comment to [EMAIL PROTECTED] archived at
http://lists.w3.org/Archives/Public/xsl-editors/2001OctDec/0043
This question of yours started quite a discussion. Specifically,
section 5.9.12 Expression Value Conversions allows for the automatic
conversion of NCNames to strings. This allows, for example, one
to say font-family=Arial. The expression evaluator should evaluate
the property value to be an NCName and then realize the datatype of
the property is string and do the automatic conversion.
However, we note that something like format=1 would not, in fact,
work, since 1 is not an NCName. Therefore, format=1 would actually
be an error. (The correct syntax would have to be format='1'.)
There is no way around this, since format=substring('123',1,1)
would be a valid assignment, and format=2-1, while not a valid
assignment (because it does not evaluate to a string or NCName),
should get evaluated into the integer 1.
While we could clarify that something like format=1 is invalid,
the XSL WG figured that no implementor would implement that. (All
implementations currently accept format=1, and no one expects
they will stop doing so.) So we wanted to find a compromise that,
while respecting the XSL expression language, didn't make all
existing implementations non-compliant. This led us to say that,
while such is an error, an implementation may recover from this by
treating the value as a string. (It may signal an error and
halt, but we doubt may implementations will do that. It may also
give a warning and continue, or just recover silently.)
Still more interesting is format=1. which would get evaluated into
the integer 1 and, if then just silently converted to a string,
would end up being equivalent to format='1' instead of format='1.'
as probably intended. This led us to our final solution.
Therefore, the following is our disposition of your above comment:
---
We DECIDED to add the following Note to the description of the
string datatype in section 5.11:
Given the allowable Expression Value Conversions (section 5.9.12),
a property value of type string must be a quoted value, an NCName,
or a expression that evaluates to a string; anything else (e.g.,
an integer) is an error. An implementation may recover from this
error by treating the unevaluated property value as a string.
--
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]
