with attachments
On Mon, Apr 23, 2012 at 8:26 AM, Glenn Adams gl...@skynav.com wrote:
I just tried this with the font you referenced and had no problem.
Attached is the configuration file and input file I used and resulting
output. I'm using the current FOP 1.1dev (trunk) build.
As Chris
please provide the following info:
(1) version of FOP you are using and platform on which you are running it
(2) a maximally minimal input FO file that demonstrates your problem
(3) the output PDF file produced by this input file (1)
(4) the FOP xconf file you used to create (3)
(5) all console
Glenn Adams gl...@skynav.com
wrote:
firstly, FOP 1.0 does not support Arabic or bidirectional
languages;
however, the current development trunk, which will lead to a new
version
FOP 1.1, does support Arabic; to download a nightly build snapshot
of the
current trunk, see [1]; for preliminary
beg pardon, but that's an operational problem on your end, not FOP; you
need to work with your FO content provider to fix it, not on this ML...
of course, if you have a general usage question, please do pose it here
i believe luis and chris have addressed your questions
On Tue, Apr 17, 2012 at
something wrong.
Glenn Adams-2 wrote:
beg pardon, but that's an operational problem on your end, not FOP; you
need to work with your FO content provider to fix it, not on this ML...
of course, if you have a general usage question, please do pose it here
i believe luis and chris have
you say in your document:
Regular PDF file does not support such extra characters in basic fonts and
- according to common opinion - it's necessary to use embedded True type
fonts. This will add extra 300KB to final PDF document.
is the 300KB number just a guess or have you verified it? the use
On Tue, Mar 27, 2012 at 2:57 PM, Tomasz Judycki tjudy...@tv.com.pl wrote:
**
W dniu 2012-03-27 21:41, Glenn Adams pisze:
(1) you use tabs in your changes to source materials (e.g., the
Helvetica*.xml files); these need to be replaced with SPACE characters only;
I didn't noticed that, I'm
A little experimentation quickly shows:
(1) removing all but one row doesn't change behavior; however
(2) removing the fo:inline parent that contains the table (and moving the
font size property to the parent fo:block) fixes the problem
Did you really intend to nest the table in an inline?
G.
.
** **
I will test your work around and get the information to the customer.
Maybe we will just have to add ‘remove fo:inline’ as part of the recipe.**
**
** **
Tom
** **
*From:* Glenn Adams [mailto:gl...@skynav.com]
*Sent:* Wednesday, March 14, 2012 2:12 PM
*To:* fop-users
It looks like this bug was already reported at
https://issues.apache.org/bugzilla/show_bug.cgi?id=47192
I added the trimmed down version of your FO file to this bug report as an
attachment.
2012/3/14 Glenn Adams gl...@skynav.com
I believe it is a bug, and am getting ready to create one
I also notice the following listed at [1]:
*inline_block_nested_3.xml* (NPE for table inside an inline):
Placing a table as a child of an fo:inline produces a NullPointerException.
[1] http://xmlgraphics.apache.org/fop/1.0/knownissues_overview.html
On Wed, Mar 14, 2012 at 1:45 PM, Glenn Adams
I can't comment on this, since (1) the current CS work is based on FOP 1.0+
(i.e., the current FOP trunk) and not FOP 0.95, and (2)
you have not provided any example XSL-FO content to check the problem;
I would suggest you build and test the current CS work at
git://github.com/skynav/fop.git
is stable, would be happy to test
it out.
Regards,
Dilip
*From:* Glenn Adams gl...@skynav.com
*Sent:* Wednesday, November 30, 2011 10:57 AM
*To:* fop-users@xmlgraphics.apache.org
*Cc:* dilipvs...@hotmail.com
*Subject:* Gujarati Support [Was: How To Implement Ligature For Indian
Languages
That's a good question. That is how it is named in the FOP trunk, and has
been for a long time apparently. I agree that fop.bat would be preferable
for Win platforms. I'll suggest this be changed in trunk, in which case I
can merge into my dev repo.
I never use fop.cmd myself for my development
yes; i started work on this (Gujarati) a few days ago
On Wed, Nov 30, 2011 at 8:24 AM, dilipvshah dilipvs...@hotmail.com wrote:
Are we still shooting for the end of the year release?
Dilip
dilipvshah wrote:
I wish to use XSL-FO technology to generate PDF documents in Indian
Gujarati OpenType (1.5 or later) fonts you
would like me to verify?
[1] http://gu.wikipedia.org/wiki/મુખપૃષ્ઠ
Regards,
Glenn
On Wed, Nov 30, 2011 at 8:39 AM, Glenn Adams gl...@skynav.com wrote:
yes; i started work on this (Gujarati) a few days ago
On Wed, Nov 30, 2011 at 8:24 AM, dilipvshah
documents you generate and once the code is stable, would be happy to test
it out.
Regards,
Dilip
*From:* Glenn Adams gl...@skynav.com
*Sent:* Wednesday, November 30, 2011 10:57 AM
*To:* fop-users@xmlgraphics.apache.org
*Cc:* dilipvs...@hotmail.com
*Subject:* Gujarati Support [Was: How
Just committed a fix for relative fo:block-container indents in bidi
context at http://github.com/skynavga/fop.
I think this takes care of all the issue you have reported. Let me know if
you run into further problems.
G.
On Sun, Nov 27, 2011 at 7:51 AM, Glenn Adams gl...@skynav.com wrote:
Hi
On Wed, Mar 30, 2011 at 9:43 PM, Glenn Adams gl...@skynav.com wrote:
Matthias,
I just updated my working repo git://github.com/skynavga/fop.git with
fixes for fo:table and fo:list-block to account for RTL writing modes;
i.e., table column progression and list-item (label and body) alignment
See also http://github.com/skynavga/fop.
On Sun, Nov 27, 2011 at 7:51 AM, Glenn Adams gl...@skynav.com wrote:
Hi Matthias,
I've updated my working repo git://github.com/skynavga/fop.git with a fix
for fo:leader to account for RTL writing modes. Let me know if you have any
problems.
I'm
- specify a larger JVM heap size when running FOP
- increase VM paging area allocation
- buy more memory
- divide your FOP file into multiple files, processed separately (rather
than multiple page sequences in one document)
On Mon, Nov 7, 2011 at 1:07 AM, KAMOHELO MOFOKENG
another tool.
Regards,
Kamo
*From:* Glenn Adams gl...@skynav.com
*To:* fop-users@xmlgraphics.apache.org; KAMOHELO MOFOKENG
kamohelo2...@yahoo.com
*Sent:* Monday, November 7, 2011 10:20 AM
*Subject:* Re: Multiple Page Sequences
- specify a larger JVM heap size when running FOP
I haven't researched the code, but perhaps someone more familiar with this
area of FOP can provide a quick answer to the following question:
Is there any way to import either a PDF file or a FOP file as an
external graphic into FOP?
I'm aware of
Do you happen to use an SVG file in your content? If so, there was a bug in
mapping SVG font sizes into FOP font sizes, which has been fixed in the
current trunk, but was not fixed in FOP-1.0. You might try using the current
trunk instead of FOP-1.0.
G.
On Wed, Oct 26, 2011 at 9:16 PM, Heiko
content. :(
Am 26.10.2011 15:22, schrieb Glenn Adams:
Do you happen to use an SVG file in your content? If so, there was a bug in
mapping SVG font sizes into FOP font sizes, which has been fixed in the
current trunk, but was not fixed in FOP-1.0. You might try using the current
trunk instead
and is
ready for alpha-testing.
Dilip
Glenn Adams-2 wrote:
Dilip,
Thanks for your offer of test data. What I need is a UTF-8 encoded text
file
containing Gujarati word forms, one form on each line. If that data is
available in an unencumbered form on the Web, then let me know a link
Dilip,
Thanks for your offer of test data. What I need is a UTF-8 encoded text file
containing Gujarati word forms, one form on each line. If that data is
available in an unencumbered form on the Web, then let me know a link for
downloading. Otherwise, I would need you to post it as an attachment
Note the messages further up:
[echo] JAI Support NOT Present
[echo] JUnit Support NOT Present - Committers are required to have
JUnit working
[echo] XMLUnit Support NOT Present - you can get it from
http://xmlunit.sourceforge.net
You need too install support for JAI, JUnit, and
. Is
this a font that the complex script work will support? Does it support
Microsoft Arial now?
** **
We realize that complex script support is a massive effort and we
especially appreciate Glenn Adams work in moving this project forward.
** **
Best Regards,
Jonathan Levinson
supply an FO (not XLST) input file if you wish to have your input examined;
make sure to supply all referenced resources
On Thu, Oct 6, 2011 at 9:30 PM, Mike Chambers m...@watchfront.co.uk wrote:
Hi,
I am getting this runtime error:
org.apache.fop.fo.ValidationException:
In general, FOP does not support the use of characters outside the Unicode
Base Multilingual Plane (BMP), i.e., characters whose scalar value is
greater than 65535 (decimal).
Support for extra-BMP Unicode codepoints will require an upgrade to the
current code base. As you can see by the error
There are two questionable assumptions you seem to make below:
(1) that FOP chooses (filters) metadata elements based on lang, i.e., FOP
implements the semantics of rdf:Alt;
(2) that FOP would fix-up non-conforming metadata;
Of course, the functionality in question is an extension to XSL-FO in
the following would not be valid XML, so would produce an XML parsing error
On Sun, Sep 11, 2011 at 3:48 PM, Terence M. Bandoian tere...@tmbsw.comwrote:
Does it make sense to specify something like the following?
dc:title
rdf:Alt
rdf:li xml:lang=\x-default\An Orange in Flight/rdf:li
nope, just the backslashes are the problem
On Mon, Sep 12, 2011 at 12:54 PM, Terence M. Bandoian tere...@tmbsw.comwrote:
On 9/12/2011 6:20 AM, Glenn Adams wrote:
the following would not be valid XML, so would produce an XML parsing
error
On Sun, Sep 11, 2011 at 3:48 PM, Terence M
, Aug 31, 2011 at 6:36 AM, Eric Douglas edoug...@blockhouse.comwrote:
**
Once someone has valid XSLFO and they're not getting the expected output
then it's an FOP question.
--
*From:* Glenn Adams [mailto:gl...@skynav.com]
*Sent:* Tuesday, August 30, 2011 11:41 PM
s/the publishing of XSL 1.0/the publishing of XSL-FO 1.0/
On Wed, Aug 31, 2011 at 10:19 AM, Glenn Adams gl...@skynav.com wrote:
I completely agree with the last sentence in your email. When I talk about
mis-spending time, I am referring to discussions about the process of
creating a valid
actually, this is an FO issue, not XSL, since it is FOP that generates page
numbers via fo:page-number
the correct answer is that you need to use the initial-page-number property
on fo:page-sequence to specify a different starting number than is generated
by auto;
see
, I often wish it did not support this convenience function.
But that's neither here nor there.
G.
On Tue, Aug 30, 2011 at 9:12 AM, Christopher R. Maden cr...@maden.orgwrote:
On 08/30/2011 10:52 AM, Glenn Adams wrote:
actually, this is an FO issue, not XSL, since it is FOP that
generates page
could you send me an example FO of what is not working for you regarding
page numbering in RTL context?
On Wed, Aug 24, 2011 at 1:03 AM, Theresa Jayne Forster
ther...@inbrand.co.uk wrote:
Page numbering, I use the page numbering for numbers on the page as well as
for the contents page .
implemented changes needed to reverse page numbering, but it
is on my list of TODO items. Thanks for reminding me.
** **
Regards,
Glenn
/quote
** **
Theresa
** **
*From:* Glenn Adams [mailto:gl...@skynav.com]
*Sent:* 24 August 2011 08:31
*To:* fop-users
? In any case,
I've added ticket http://skynav.trac.cvsdude.com/fop/ticket/66 to track this
issue.
On Wed, Aug 24, 2011 at 8:31 PM, Glenn Adams gl...@skynav.com wrote:
Theresa,
I'm not sure whether you are referring to a problem with correct bidi
treatment of the inline character areas generated
R-L columns are still outstanding.
What do you mean by R-L numbering?
Regards, Glenn
On Tue, Aug 23, 2011 at 3:52 AM, Theresa Jayne Forster
ther...@inbrand.co.uk wrote:
Hi all,
** **
Just looking for information on the current status of compliance for Arabic
fonts, I know there is
pipe stderr through 'grep -v' or 'awk' or 'sed', etc.
On Mon, Aug 15, 2011 at 2:50 PM, Rita Greenberg rgreenb...@medata.comwrote:
Hello.
I've just converted some .fo files from FOP 0.20.5 to FOP 1.0.
I get a warning message regarding collaping border model as follows:
WARNING: In
(connectivity, direction and fonts of Arabic) Datum: Fri, 29 Jul 2011
04:11:26 GMT Von: Glenn Adams gl...@skynav.com gl...@skynav.com
Hello Qais,
Thanks for taking some time to test out the complex script features being
developed for FOP.
To help address these issues, could you:
(1
as requested above, I'm
sure we can resolve this matter soon. Also, if you haven't already seen it,
please take a look at the documentation and active tickets found at
http://skynav.trac.cvsdude.com/fop.
Regards,
Glenn Adams
On Wed, Jul 27, 2011 at 1:57 PM, Qais m.q...@gmx.de wrote:
Hi,
Since a week I
?
org.apache.fop.fo.ValidationException: {
http://www.w3.org/1999/XSL/Format}block; is not a valid child of
fo:table-row! (See position 1143:945)
On Fri, Jul 15, 2011 at 9:42 AM, Chris Bowditch
bowditch_ch...@hotmail.com wrote:
On 12/07/2011 12:11, Glenn Adams wrote:
this is not a bug, as pointed out
this is not a bug, as pointed out by Pascal
On Tue, Jul 12, 2011 at 5:08 AM, Chris Bowditch
bowditch_ch...@hotmail.comwrote:
On 12/07/2011 09:52, tecshine wrote:
Hi,
Thanks for the reply Pascal
I have tried using fopFactory.**setStrictValidation(false); but it doesnt
solve the problem.
for Bengali is being tracked at
http://skynav.trac.cvsdude.com/fop/ticket/51.
Regards,
Glenn Adams
On Sun, Jun 19, 2011 at 11:53 PM, Rajat Narain narain.ra...@gmail.comwrote:
I have just downloaded the latest binary dt. 15.06.2011 and performed a
small test for indic fonts, namely Bengali and find
You know, given the time spent answering questions about XSL and the XML+XSL
- XSL-FO front-end (convenience mechanism) in FOP, I sometimes wonder if
it would be better to rip out that function. Perhaps then folks would
understand better that FOP is fundamentally an XSL-FO - output format
Of course, an extension can do anything you want. But you have to define it
and write the Java that implements it.
Again, I question the basis of your question. The XSL-FO tree starts out as
an XML document, having the root node of fo:root, and adhering to the XSL-FO
specification. You should
reported problems. I hate to
ask, but could you please fix issue # 1 (fo:page-number-citation) soon? That
would be of great help.
Thanks!
Matthias
On 13.05.2011 11:36, Glenn Adams wrote:
Matthias,
Thanks. Yes, it would be helpful if you could send me minimal test cases
for these issues
I would recommend using the following because it is the most up to date
version of the Complex Scripts work (the SVN version that Peter references
below is somewhat behind in terms of bug fixes, etc):
http://github.com/skynavga/fop
See branch i18n.arabic. Also see documentation at
keep in mind that you do not have to use FOP to perform the XSL to FO
transformation; you can use other tools outside of FOP to perform the
transformation, and then feed the resultant XSL-FO file to FOP;
On Fri, Jun 3, 2011 at 7:04 AM, Theresa Jayne Forster ther...@inbrand.co.uk
wrote:
On that
XSLT != XSL-FO
Completely different languages.
G.
On Fri, Jun 3, 2011 at 8:30 AM, Theresa Jayne Forster ther...@inbrand.co.uk
wrote:
Ok I cannot see what is wrong here,
A test app does this
Fop fop =
fopFactory.newFop(MimeConstants.MIME_PDF,useragent,out);
length in XSL-FO is as defined by CSS 2. A unit designator is required
unless the value is 0. The available unit designators are:
- em
- ex
- in
- cm
- mm
- pt
- pc
- px
The unit 'pt' is an absolute measurement equal to 1/72 inch. FOP
non-conformantly permits unit-less
=0,0,556,84svg:path d= M 0.00 0.00 L
0.30 0.00 ...
Can I assume that is pt? I'm assuming page size is 792 x 612 (or 612 x 792
landscape).
--
*From:* Glenn Adams [mailto:gl...@skynav.com]
*Sent:* Thursday, June 02, 2011 10:36 AM
*To:* fop-users
'heavy' is not defined by XSL-FO, the admissible values are as defined by
CSS2:
CSS2 Definition:
*Value:*normal | bold | bolder | lighter | 100 | 200 | 300 | 400 | 500 | 600
| 700 | 800 | 900 | inherit *Initial:*normal *Inherited:*yes *Percentages:*
N/A*Media:* visual
CSS2 Reference: font-weight
process and creation of
org.apache.fop.fonts.Font any native methods from the JRE are used?
Cheers,
Dieter
On Sat, May 21, 2011 at 10:28 PM, Glenn Adams gl...@skynav.com wrote:
FOP reads native fonts directly, but does not create java.awt.Font as a
result; rather, it creates instances
FOP reads native fonts directly, but does not create java.awt.Font as a
result; rather, it creates instances of org.apache.fop.fonts.Font, an
instance of which internally holds a reference to an object implementing
org.apache.fop.fonts.FontMetrics, the latter holding most of the information
parsed
.
Best regards,
Matthias
On 31.03.2011 00:43, Glenn Adams wrote:
Matthias,
I just updated my working repo git://github.com/skynavga/fop.git with
fixes for fo:table and fo:list-block to account for RTL writing modes; i.e.,
table column progression and list-item (label and body) alignment
references only sometimes work
3. start-indent on fo:block with a block-container child isn't taken into
account.
Please let me know, if you want me to prepare a test case showing all three
issues.
Best regards,
Matthias
On 31.03.2011 00:43, Glenn Adams wrote:
Matthias,
I just updated my
it needs to go right
hand column to left
Theresa
*From:* Glenn Adams [mailto:gl...@skynav.com]
*Sent:* 13 May 2011 15:40
*To:* fop-users@xmlgraphics.apache.org
*Subject:* Re: Complex Script, BIDI text supported?
Theresa,
The current code in git://github.com/skynavga/fop.git DOES
You can track the status of these defects at:
- right-to-left page numbering -
http://skynav.trac.cvsdude.com/fop/ticket/33
- right-to-left flow column progression -
http://skynav.trac.cvsdude.com/fop/ticket/34
Regards,
Glenn
On Fri, May 13, 2011 at 9:27 AM, Glenn Adams gl
committed for these issues.
G.
On Wed, Mar 23, 2011 at 6:45 AM, Glenn Adams gl...@skynav.com wrote:
Thanks for uncovering these issues. Let me address them and I'll let you
know when they are fixed in my GIT repo. Perhaps after that I can submit a
new patch update for the SVN branch.
G
Glenn Adams-2 wrote:
Matthias,
I've fixed the fo:block-container problem as well as text-align and
treatment of writing-mode on page regions. The fixes are present in my
GIT
repo I referred to earlier (and also include all trunk commits up to
this
point). To be a little more detailed
I've been working in the background on a patch that adds support for using
newer PDF features, including page transitions and option groups, and in
this work defined an new element in the FOP CONF file as follows to specify
the PDF output version:
?xml version=1.0?
fop version=1.0
in and help, I am just not certain where to start.
Thanks,
Josh
*From:* Glenn Adams [mailto:gl...@skynav.com]
*Sent:* Tuesday, March 08, 2011 6:40 PM
*To:* fop-users@xmlgraphics.apache.org
*Cc:* Marquart, Joshua D
*Subject:* Re: Font Weight
FOP does not synthesize fonts with different
Matthias,
Thanks for the report. Could you send me the FO input file and PDF output
file? I am actively testing and fixing the Bidi and Script support, with
real-time updates occurring at git://github.com/skynavga/fop.git.
Regards,
Glenn
On Wed, Mar 9, 2011 at 11:28 AM, Matthias Reischenbacher
*From:* Glenn Adams [mailto:gl...@skynav.com]
*Sent:* Wednesday, March 09, 2011 12:02 PM
*To:* Marquart, Joshua D
*Cc:* fop-users@xmlgraphics.apache.org
*Subject:* Re: Font Weight
Josh,
What you have not said yet is whether you actually have (on your system) a
font with the desired weight
with the apache SVN branch.
Thanks Regards,
Matthias
Glenn Adams-2 wrote:
Matthias,
Thanks for the report. Could you send me the FO input file and PDF output
file? I am actively testing and fixing the Bidi and Script support, with
real-time updates occurring at git://github.com
a lot for your help!
Matthias
Glenn Adams-2 wrote:
It appears the problem is due to a bug related to the use of
block-container, which I will look into. However, if you remove
block-container, and put the writing-mode and (default) font-family on
fo:page-sequence, it should produce
FOP does not synthesize fonts with different weights. You need to supply the
fonts with the weights you specify in FO content.
Regards,
Glenn
On Tue, Mar 8, 2011 at 4:31 PM, Marquart, Joshua D
joshua.marqu...@firstdata.com wrote:
I have a question about Font Weight.
We’re using Helvetica
This is a bug in FOP's native SVG rendering code, which maps SVG's bold to
600 instead of 700. I just reported this recently.
Glenn
On Mon, Mar 7, 2011 at 3:21 AM, Régis Fénéon regis.fen...@free.fr wrote:
Hello,
I'm trying the fop trunk version and now I get warning messages when I
generate
You did not provide the most important details, namely the input FO and the
output PDF. In any case, it is most likely that you are not specifying a
font that contains the desired character. Try specifying
fo:inline font-family=Arial Unicode MS#x8594;/fo:inline
Of course, you will need to make
OTF are already supported. However, some features of OTF are not supported.
Regards, Glenn
On Wed, Feb 2, 2011 at 6:10 AM, Peder peet@gmail.com wrote:
But the problem really springs from the fact that FOP doesn't support
opentype fonts.
Are there any plans to support opentype fonts in
sounds like you should be using SVG, not FOP; FOP is all about making
placement decisions, SVG is all about rendering to the author defined
positions
glenn
On Mon, Jan 24, 2011 at 8:39 AM, Eric Douglas edoug...@blockhouse.comwrote:
If you're just printing a book as a bunch of text which does
for the Postscript
renderer (and other renderers).
Regards,
Glenn Adams
On Mon, Oct 25, 2010 at 7:17 PM, Imad Moussa Daou imad.m.d...@gmail.comwrote:
Dear,
I am Imad Daou and I have been using FOP from about 1 year and I was
satisfied from it's results until I tried it with Arabic which is my
note that because Arial Unicode MS is an embeddable font, FOP will
automatically embed the referenced glyphs in the output PDF; so you will
likely find it unnecessary to distribute the font with the PDF output;
furthermore, if I recall correctly, this font is under license from AGFA
Monotype and
In regards to XSL-FO, you need to understand the meaning of the
line-stacking-strategy property as defined by
http://www.w3.org/TR/2006/REC-xsl11-20061205/#line-stacking-strategy
and as used by
http://www.w3.org/TR/2006/REC-xsl11-20061205/#area-line
Unfortunately, it is a rather complex topic.
, but most of them).
They are: Bulgarian, Czech, Danish, Dutch, English, Estonian, Finnish,
French, German, Greek, Hungarian, Irish, Italian, Latvian, Lithuanian,
Maltese, Polish, Portuguese, Romanian, Slovak, Slovene, Spanish and Swedish.
On Tue, Sep 28, 2010 at 2:19 AM, Glenn Adams gl
probably more pdf readers support 1.4 than 1.7; also, PDF 1.7 does not have
any particular features that 1.4 does not have that relate to multiple
language support;
which languages do you require support for?
regards,
glenn
2010/9/27 Daniel Sánchez González dsanch...@gmail.com
We need
not at present (presently it uses 1.4);
however, on my list of tasks is upgrading to support 1.7, and particularly
to add support for some of the transition/animation features of 1.7; i will
post to this list when a patch is available;
regards,
glenn adams
2010/9/27 Daniel Sánchez González
would you happen to be running as root user (uid 0), or non-root? i recently
encountered a similar problem on 1.0 when running junit tests as root; the
other thing to check is verify you are using xmlgraphics-commons-1.4.jar and
batik-all-1.7.jar;
On Thu, Sep 16, 2010 at 3:42 PM, dvzoerlandt
i would suggest the following:
1. copy avgardm.ttf into ~/Library/Fonts
2. remove ~/.fop/fop-fonts.cache
3. change your config to:
fonts
auto-detect/
/fonts
4. re-run FOP (but don't run TTFReader)
On Fri, Sep 10, 2010 at 1:53 PM, ali naqi ali.n...@coeus-solutions.dewrote:
Okay
-fonts.cache ... Could not find .fop/fop-fonts.cache
3. change your config to: ... DONE
fonts
auto-detect/
/fonts
4. re-run FOP (but don't run TTFReader) ... DONE
Result: didn't work :(
On Fri, Sep 10, 2010 at 8:04 AM, Glenn Adams gl...@skynav.com wrote:
i would suggest
try adding xml:space='preserve' and white-space-collapse='false' to the
inline element; also you can try substituting non-breaking space #x00A0;
On Wed, Sep 8, 2010 at 6:30 PM, Bas van den Broek
bas.van.den.br...@mendix.com wrote:
Hello all,
I’ve generated an FO file based on XHTML using
Have you checked that you are using UTF-8 encoding in your FO file? If you
read the exception below, it is complaining about the coding in the input
file.
G.
On Mon, Aug 30, 2010 at 12:35 AM, Nikolaos Paraschou nipar...@gmail.comwrote:
Hello,
This is the first time I am using Apache FOP. I
New
Roman, and both render successfully.
G.
On Mon, Aug 30, 2010 at 9:06 AM, Glenn Adams gl...@skynav.com wrote:
Have you checked that you are using UTF-8 encoding in your FO file? If you
read the exception below, it is complaining about the coding in the input
file.
G.
...@leverkruid.euwrote:
We are happy to let you know that Complex Script Support for FOP is
under development. Glenn Adams is developing this functionality on
behalf of Basis Technologies.
To make this development efficient and successful, we need your
contribution as well. Does your native
shall then have full support for Arabic, Hebrew, Syriac, and other
bidirectional scripts.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49687
I will post further information on this users list when the work is complete
and integrated into the FOP 1.1dev trunk.
Regards,
Glenn Adams
On Thu
201 - 290 of 290 matches
Mail list logo
