Re: Can't commit
On 3/24/07, Jay Bryant <[EMAIL PROTECTED]> wrote: ...svn: MKACTIVITY of '/repos/asf/!svn/act/8cd4ce0b-68b0-9b4f-b65f-2c1a9a53a96f': 403 Forbidden (http://svn.apache.org)... You need to switch your SVN URL to https, see http://www.apache.org/dev/committers.html#commit-403 -Bertrand
Re: FOrayFont integration in question
Hi Vincent and team, I won't comment on the whole thing as IMO there's one element which narrows down the choices a lot (but thanks for the detailed explanations): On 11/13/06, Vincent Hennebert <[EMAIL PROTECTED]> wrote: ...FOrayFont is mainly a one-man-show and it's not very good for Fop to have such a dependency... I think having such a dependency on a one-man show project for a key part of FOP would be a bad idea. Even if the one man was Knuth himself...well, maybe we'd make an exception for Knuth, but not for mere mortals. So, IMHO the only remaining options are either to fork aXSL, or to not use it in FOP. As you mention, FOP's font stuff is not far from aXSL's stuff today. One thing that you didn't mention is the handling of OpenType fonts with PostScript (CFF) outlines, does aXSL do that? -Bertrand
Re: Kerning for CID fonts, use unicode indexes in ?
On 10/13/06, Jeremias Maerki <[EMAIL PROTECTED]> wrote: ...Maybe I'll try to figure out if it's a small change to bypass the metrics file entirely. :-) Shouldn't be hard at all, but right now I have to create a test document to demonstrate the "new" font features for my own project, so I won't be able to do it ATM. I hear you work well on trains ;-) -Bertrand
Re: Kerning for CID fonts, use unicode indexes in ?
On 10/11/06, Jeremias Maerki <[EMAIL PROTECTED]> wrote: ...I wonder how much should be invested in versioning of those files Ok, so I have added a simplistic versioning system for these metrics XML files, an exception is thrown when attempting to read incompatible metrics files (http://issues.apache.org/bugzilla/show_bug.cgi?id=40739). Mapping the glyph indexes to unicode indexes when reading the XML metrics file seemed more complicated than when creating the file, so I have implemented the change in the TTFFile class, which now writes the info based on unicode code points. A note in the FOray release notes (http://foray.sourceforge.net/app/using/release.html) says "Kerning has been fixed for subsetted fonts", makes me wonder if kerning did work before for custom CID fonts. Anyway it should work now. -Bertrand
Re: Kerning for CID fonts, use unicode indexes in ?
On 10/11/06, Jeremias Maerki <[EMAIL PROTECTED]> wrote: ...the goal should be that we don't rely on those XML files much longer, so I wonder how much should be invested in versioning of those files... Agreed - versioning is easy though, if I need to make the suggested changes I'll probably implement it just to be safe, before going to direct reading of the font files. ... I still don't understand why exactly this change is necessary The layout code definitely expects unicode indexes for the kerning values, so something's wrong currently. I'll see how mapping on the other side (i.e. when reading the metrics xml file) looks, as it would avoid having to modify the metrics xml files. -Bertrand
Re: Kerning for CID fonts, use unicode indexes in ?
On 10/11/06, Jeremias Maerki <[EMAIL PROTECTED]> wrote: ...If this change has an effect on the XML files generated, then we should be careful because people might not recreate their metric files and subsequently run into problems... How about adding a version number to the XML metrics files? This would make them more future-proof, and in this case we could detect old files and bark. -Bertrand
Kerning for CID fonts, use unicode indexes in ?
Hi FOPpers, See http://issues.apache.org/bugzilla/show_bug.cgi?id=40724 , kerning doesn't work for me with user-specified CID fonts at the moment. IIUC the code, org.apache.fop.layoutmgr.inline.TextLayoutManager expects unicode indexes for kerning pairs, but currently the TTFReader writes glyph indexes in the XML file, like: Where 3 and 4 are glyph indexes (I'm playing with a test font with very few glyphs, it's easier). I've tried changing the TTFFile code to use unicode indexes for kpx1 and kpx2 and it seems to work - anything against making this change? -Bertrand
Re: svn commit: r462726 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fonts/MultiByteFont.java fonts/truetype/TTFFile.java pdf/PDFToUnicodeCMap.java
On 10/11/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: URL: http://svn.apache.org/viewvc?view=rev&rev=462726 Log: code style TAB characters license headers... Sorry about that - sloppy work from me here. I must admit that I hate checkstyle's rigid rules when they get in the way sometimes (where common sense would let you bend them creatively) , but I'll do my best...and get Eclipse configured correctly on my new machine (iMac 17 inch core 2 duo - great value when combined with a second screen). -Bertrand
Re: Hi from the Cocoon GetTogether in Amsterdam
On 10/3/06, Jeremias Maerki <[EMAIL PROTECTED]> wrote: ...Big thanks to the Cocoon community for letting us take part in their event... With my Cocoonista hat on: thanks to you FOP guys for being here, there are definitely synergies between our projects and it's good to see that happen IRL as well. -Bertrand
FYI: committing Vincent's code to the foray-font branch
Hi FOPpers, I'm going to commit code from Vincent's patch [1] probably later today, to the foray-font branch, as we're going to work on it together in the next few days. As it's a really big patch, I assume it's ok to do that without waiting for other committers to review the patch. Vincent has an ICLA on file, so we're clean w.r.t to ASF policies, and we know him well enough to trust his code. And at the moment it's just a branch anyway ;-) -Bertrand [1] http://issues.apache.org/bugzilla/show_bug.cgi?id=35948
Re: Re: Signup for the Cocoon GT Hackathon
On 9/22/06, Vincent Hennebert <[EMAIL PROTECTED]> wrote: I know about nothing of Cocoon, will that be a problem? :-/... I'm sure Cocoonistas will be delighted to have you guys around. -Bertrand
Re: Re: Signup for the Cocoon GT Hackathon
On 9/22/06, Jeremias Maerki <[EMAIL PROTECTED]> wrote: Added myself. The Cocoon Serializer is a good idea, IF!!! Maven is kind with me this time. ;-)... I might get some flak from the Cocoon team for saying this, but I think a FOP trunk serializer would be good for Cocoon 2.1.x as well (the 2.1 build does not use Maven, it's only 2.2 which uses Maven). Many people still use Cocoon 2.1, and this is especially true of people who use it "only" for publishing purposes, IMHO. -Bertrand
Signup for the Cocoon GT Hackathon
Hi FOPpers, As I think some of you are coming to the Cocoon GetTogether: you're welcome to sign up at http://wiki.apache.org/cocoon/GT2006Hackaton. I have added "creating a Cocoon serializer for the current FOP release" as a hacking idea. Not sure if I'll have much time to work on this myself, but it'd be very nice to have. -Bertrand
Re: Re: Committing again..
On 9/18/06, Simon Pepping <[EMAIL PROTECTED]> wrote: ...Why don't you start a branch? That gives you more room for experimenting... Good idea. I'm starting with the the ToUnicode stuff which might not justify a branch, but a branch for the OpenType/fonts stuff makes sense. -Bertrand
Committing again..
I hope it's ok if I commit my work on OpenType fonts directly - I haven't committed anything here for a looong time, but still have commit rights. I'll do my best not to break anything, and also to include automated tests for my changes. -Bertrand
Looking for OpenType fonts to distribute with FOP, for testing
Hi FOP community, I'm working on OpenType font support improvements [1], and I'm trying to get permission to distribute some OpenType fonts with FOP to test and demonstrate this. If anyone has good fonts that they could donate, or contacts to help make this happen, please let me know! -Bertrand [1] http://issues.apache.org/bugzilla/showdependencytree.cgi?id=40464
Bugzilla component added: "fonts"
I have added a new "fonts" component in the list of components for FOP, in bugzilla. Hope it's ok - If not, just yell ;-) -Bertrand
Re: Re: Re: Implementing OpenType font support, how hard?
On 8/4/06, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote: ...I'll discuss the plan with my project's stakeholders and hopefully get the green light to invest time in this... Good news, I got the green light and will be working on these OpenType improvements in the next few weeks. I'll use the dependencies of issue 40464 [1] to document my progress, and of course discuss the details here. -Bertrand [1] http://issues.apache.org/bugzilla/showdependencytree.cgi?id=40464
Re: Re: Implementing OpenType font support, how hard?
On 8/3/06, Jeremias Maerki <[EMAIL PROTECTED]> wrote: ...Sorry, I haven't been clear. Adam obviously grabbed a class [1] from Victor's FOray, adapted it to FOP and put a different license header on top. So, it's not that simple. As a first point, we'll need a license grant from Victor for this file or get him to commit it himself to FOP under his ICLA or we use his file and modify it without removing the original license header (I don't like that last option). Not sure how best to deal with this Ok, thanks for the clarification. I'll see if Victor would agree to donate this one class as a temporary solution, until FOP uses FOray. If not I'll write another implementation. Again, thanks everybody for your comments - I'll discuss the plan with my project's stakeholders and hopefully get the green light to invest time in this. -Bertrand
Re: Re: Implementing OpenType font support, how hard?
On 8/3/06, Manuel Mall <[EMAIL PROTECTED]> wrote: On Thursday 03 August 2006 21:04, Simon Pepping wrote: >... The main problem with all these smart font features is that you > cannot implement them in rendering without also implementing them in > the linebreaking code ...That comment does not only apply to line breaking, justification, hyphenation, word spacing, are all affected. That is layout needs to know the exact metrics the renderer is going to use. Doesn't kerning cause the same problem as smart font features (like automatic ligatures)? It also causes the total width of a group of character to change when the group is split between two lines. -Bertrand
Re: Re: Implementing OpenType font support, how hard?
Hi, and thanks everybody for your replies. On 8/2/06, Jeremias Maerki <[EMAIL PROTECTED]> wrote: ...No, I've been able to restore kerning support. If there's still some commented code I should probably remove it now. Can you give me a pointer?... You're right, kerning works for builtin fonts at least. It doesn't seem to work in my tests with user-specified fonts, but I've just done a quick test. ...I wonder if supporting Type 1 outlines would be worth the effort. So far, I've never seen an OpenType font with Type 1 outlines. Have you?... Seems like most of the standard OpenType fonts on my MacOSX system use Type 1 outlines. But you're right that supporting TrueType outlines would be a good start already. > 2c) Verify that the character encodings are correct... ...The problem is that FOP does not currently support generating a ToUnicode table. Victor Mote has the fixed in FOray and we have a patch in Bugzilla that uses that code to do the same for FOP. Since nobody has dealt with the legal part of grabbing someone else's code in this case, the patch hasn't been applied, yet. The patch: http://issues.apache.org/bugzilla/show_bug.cgi?id=5335 IIUC what's needed here is to contact Adam Strzelecki, author of the patch, and ask him to "Grant license to ASF for inclusion in ASF works (as per the Apache Software License §5)"? This is how things are done when patches are uploaded via http://issues.apache.org/jira. ...Finishing 2) would then also mean finishing FOrayFont to the degree that it can be used in FOP. I guess that will need further deliberation... I've studied FOray and integrating it is probably out of scope for my current work. It doesn't look too hard, but it impacts quite a lot of existing code, so I fear there might be hidden roadbumps in there. OTOH I agree that using it (and maybe re-integrating that code in FOP?) seems to make more sense than doing a lot of work on FOP's current font-handling code. Also, from other's comments in this thread, it seems like handling smart font features (glyph substitutions) might be a lot of work, better done in a (yet hypothetical) second phase once basic OpenType support works well. At this point, my plan, for a first phase, would be -Integrate Adam Strzelecki's patch to support extended character sets cleanly -Check that OpenType fonts with TrueType outlines are usable as custom fonts, including kerning. Fix things as needed, and have a look at what's needed to support Type 1/CFF outlines. -Try to get a few OpenType reference fonts that can be distributed with FOP for testing and demonstration (I'd ask some font editors, the fonts can be crippled if they want, for example by removing portions of the glyph sets). The smart fonts stuff would (maybe) come later, the above might be sufficient for my current project. I'm being much less ambitious than yesterday...but the above looks like a useful concrete step. WDYT? -Bertrand
Re: Re: Implementing OpenType font support, how hard?
Hoi Jeremias, I'll reply on the other points tomorrow, but for now: ...AFAIK, OpenType allows different variants of a font in one font file (ex. normal and bold). We've had requests to support those font files. Have you found out during your investigations what would be involved in supporting this and would this be in scope for your work?... AFAIK, several OpenType fonts can be packaged in a single file as "TrueType Collections" with a .TTC file extension. If that's what you're thinking about, extracting the individual fonts from such a file shouldn't be a problem. -Bertrand
Implementing OpenType font support, how hard?
Hi FOP team,
(sorry about the long message, but there's quite a lot of stuff to explain)
I *might* have a need and budget to improve the support of OpenType
fonts in FOP in the next few weeks.
We had a quick talk about this with Jeremias at ApacheCon EU, and now
I need to estimate how hard/long this could be.
I'll list the various steps that I imagine are needed. Please bear
with me if there's some sillyness below, I don't know much about how
FOP handles fonts so I might be totally off on some assumptions.
My target output is only PDF at this point, I haven't looked at the
issues for other formats.
If you're not familiar with what OpenType brings to fonts (in addition
to extended character sets, and usually high quality fonts), the
BelloPro tester [2] is quite convincing IMHO.
Feedback and alternative ideas are welcome!
1) My understanding of the current situation.
FOP allows user-specified fonts to be used and embedded in the generated PDF.
Provided utilities ("font file readers") convert PostScript Type 1 and
TrueType fonts to XML files storing font metrics and kerning
information.
The TrueType utility should be able to handle OpenType fonts which
contain TrueType outlines (in my tests it worked with some fonts, but
PDF embedding was not correct for the MacOSX Preview app, although
Adobe Reader was fine). OpenType fonts with Type 1 outlines are not
usable in FOP currently.
At the layout stage, FOP uses "static" font metrics to find the size
of a character: FOP asks the Font object "what are the metrics of this
character". This works one character at a time, which would prevent a
smart Font from performing ligature substitutions, for example (where
e.g. "ffi" is mapped to a single glyph).
When generating PDF, FOP embeds the font, subsetting it if it's a
TrueType font (e.g. storing only glyphs that are actually used in the
document).
Kerning does not work in the FOP trunk currently, the corresponding
code is commented out.
2) Steps for simple support of OpenType fonts
2a) Write an OpenTypeFontFileReader, factoring out and reusing code of
the TrueType and Type 1 readers to support OpenType fonts having
either Type 1 or TrueType outlines.
2b) Complete the font embedding code so that it works for both
OpenType outline variants (maybe ignoring subsetting if it makes it
easier)
2c) Verify that the character encodings are correct when embedding the
font, might need improvements? [1] seems to imply that this is
problematic currently.
2d) Re-enable kerning, as OpenType fonts are usually of high quality
and "deserve" to be used with automatic kerning.
3) Additional steps for OpenType GSUB table support
The goal is to enable the "smart font" features of OpenType, automatic
ligatures as mentioned above, language-dependent glyph substitutions
(different shapes if a letter is at the beginning of a word for
example), automatic decorative swashes at the beginning or end of
words, etc.
3a) Decode the GSUB table of the OpenType font (and other tables that
might be required to use it) and store its data in the FOP XML font
metrics file
3b) Modify the chars-to-metrics mapping to handle things like
automatic ligatures, where several chars map to a single glyph
3c) Implement GSUB table handling, glyph substitutions (or reuse an
existing library for this, but the only one that I've found is
freetype, haven't found one in Java).
3d) Create test documents to demonstrate this, asking a font provider
for a donation of some OpenType fonts to use in FOP tests.
Even this wouldn't be complete, as OpenType allows specific features
to be enabled for specific character runs, like "use alternate glyph
set 2 for this character only". But it would be a good start already
;-)
At this point I'm mostly interested in your opinion on points 1) and
2) above, if these enhancements seem realistic I might be able to work
on them in my current project. Point 3) obviously needs more work and
might not fit my budget at this point.
Thanks for any feedback on this!
-Bertrand
[1] http://xmlgraphics.apache.org/fop/0.20.5/fonts.html#embedding
[2] http://www.underware.nl/site2/index.php3?id1=bello&id2=testbello
Re: [ANNOUNCEMENT] Apache FOP 0.90 alpha 1 released
Le 23 nov. 05, à 00:23, Jeremias Maerki a écrit : The Apache FOP team is excited to announce the release of Apache FOP 0.90 alpha 1... So am I, CONGRATULATIONS to the team for making this happen! It's great to see FOP alive and kicking, with a solid team behind it. The release, and how well it is documented (http://xmlgraphics.apache.org/fop/compliance.html), leaves no doubt about the quality of what's going on here. Keep it up! -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: rtflib independance from FOP (continued) + JAFOG
Le 2 août 05, à 12:36, Chris Bowditch a écrit : ...Is this a typo, or did you mean to say FOP is *not* the most up-to-date place for thr RTF Renderer? I thought the JFOR project had stopped and since integrating the RTF Renderer into FOP, several improvements had been made to the RTF Renderer in FOP... Yes, nearly nothing much has happened on the jfor side since the code was donated to FOP. I haven't looked closely at the FOP rtflib stuff but I guess it's at least as good as jfor's, and getting better. -Bertrand smime.p7s Description: S/MIME cryptographic signature
