DO NOT REPLY [Bug 39293] - FOP can't support bold,italic for chinese/other multiplybytes fonts
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=39293. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=39293 --- Additional Comments From [EMAIL PROTECTED] 2006-04-13 08:01 --- Are you talking about TTC fonts (TrueType Collection)? If yes, that's already supported. Just follow the instructions on the FOP website. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 39293] - FOP can't support bold,italic for chinese/other multiplybytes fonts
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=39293. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=39293 --- Additional Comments From [EMAIL PROTECTED] 2006-04-13 08:08 --- i know FOP support ttc and ttf. my meaning is FOP can't support Bold and Italic pdf format output. because none of multibyte fonts support bold and italic. so ,FOP should provide another method to solve this problem. if not ,then FOP can't output correctly pdf when content include bold and italic -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 39293] - FOP can't support bold,italic for chinese/other multiplybytes fonts
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=39293. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=39293 [EMAIL PROTECTED] changed: What|Removed |Added Severity|critical|enhancement --- Additional Comments From [EMAIL PROTECTED] 2006-04-13 08:34 --- I still don't know what kind of multibyte fonts you're talking about. TrueType? OpenType? Other font formats? Anyway, it would help if you could attach a small PDF generated with one of the Adobe tool that demonstrates the feature you want. From there I can reverse-engineer and at least find out what you're after. At any rate, it's a good idea for you to find a font file for each variant of the font you want to use (normal, bold, italic, etc.) and use them. I don't think FOP will support what you want anytime soon, unless you're willing to invest time to implement this feature yourself. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 39293] - FOP can't support bold,italic for chinese/other multiplybytes fonts
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=39293. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=39293 --- Additional Comments From [EMAIL PROTECTED] 2006-04-13 08:57 --- ok. i just know truetype. multibyte languages include chinese,japanese etc. and in my ken,none of chinese fonts support variant for bold and italic. and i think other multibyte language fonts can't support those too. as you can know,common chinese characters GBK include 6700+ letters,but english only include 26! -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 39293] - FOP can't support bold,italic for chinese/other multiplybytes fonts
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=39293. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=39293 --- Additional Comments From [EMAIL PROTECTED] 2006-04-13 09:10 --- Created an attachment (id=18090) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=18090action=view) this a pdf generate by adobe acrobat 7.0 this a pdf generate by adobe acrobat 7.0 include bold,italic,bold+italic chinese characters. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 39293] - FOP can't support bold,italic for chinese/other multiplybytes fonts
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=39293. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=39293 --- Additional Comments From [EMAIL PROTECTED] 2006-04-13 09:47 --- What you are asking for is an extension to the XSL FO specification. FOP is designed to conform to that standard and the standard does not provide a function for emulating bold or italic font metrics from regular fonts. The reason you are asking for this feature is because it is hard work to create bold and italic glyphs for fonts with so many glyphs. But it is also hard work to create the feature you are asking for. Of course, patches are always welcome :) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: Release coordination in XML Graphics (was: [VOTE] Release Apache XML Graphics Commons 1.0 and Apache FOP 0.92beta)
On Wed, 2006-04-12 at 14:07 +0200, Jeremias Maerki wrote: On 12.04.2006 13:55:44 Peter West wrote: snip/ Is there other than accidental co-ordination between commons, batik and fop? Accidental? ATM, no coordination is required for releasing Commons as Batik doesn't use it, yet. The plan for XML Graphics Commons on the Wiki is still valid and provides the base for work on Commons. FOP 0.92 will still use Batik 1.6 as we can redistribute only released JAR files. No snapshot JARs as in the past. Coordination as necessary between subprojects in XML Graphics happens on [EMAIL PROTECTED] What guidance will there be for users in co-ordinating versions of the three? I don't understand the question, sorry. I had drawn the conclusion, falsely it appears, that co-ordination of the three elements was in the offing. Hence the discussion of the stability of trunk code in fop, batik and commons. I don't see how you plan to work the extraction without such co-ordination. It is an aim that the batik guys be able to commit to the transcoders. That impacts on fop. There is a question on the wiki about builds. Individual builds or one über-build? Buzzing around at the back of that question is the larger one of co-ordinating the trees. The wiki mentions that the transcoders can be used in the batik context (and others) independently of fop. However, don't the transcoders get involved in the round-trip when embedded svg elements are rendered by fop to pdf or ps? I don't know, but if so, there's a nice chain of dependency from fop - batik - fop', where fop may not currently equal fop'. The current split of fop and commons has nothing to do with batik, it seems. I was working on the assumption that the creation of commons implied the three-way compatibility of trunk elements. ...a Batik release didn't involve a FOP release until now which is something that must change. At some time in the future. I'm working on a project that uses 0.20.5, batik 1.6 and, now, the fop and batik trunk code. It looks as though I may have to unwind the batik trunk code. It seems to me that the builds of the three trees must at least utilise common build file import elements. Building fop is going to depend upon the availability of particular trunk snapshots of commons and batik. Otherwise, how do you co-ordinate development on the batik and fop and commons trunks? There are users who want release versions only, and there are users who are building from the trunk, including, but not restricted to, the developers. For the latter users, the build process must be able to determine whether the tree of primary focus has access to compatible source trees or jars for the other trees. That seems to imply that each tree maintains a range of compatible versions. Changing fop, say, may then mean updating the build files for commons and batik to reflect the fact that dependencies somewhere have just changed. That, in turn, seems to imply that the build files for all trees are maintained in commons. Peter
Re: Release coordination in XML Graphics (was: [VOTE] Release Apache XML Graphics Commons 1.0 and Apache FOP 0.92beta)
Ok, I think I'm beginning to see the problem. Looking at the Commons plan on the wiki it uses the term transcoder. That's not good. We're planning to move to the PDF and PS/EPS transcoders to Batik, not to Commons (mentioned in parantheses on the wiki page). Only the basic Graphics2D implementations will go to Commons. That will give Batik committers write access and full control over the Transcoders. FOP is not interested in the Transcoders, but it is interested in the Graphics2D implementations for handling extensions like SVG, MathML, Barcode4J etc. The dependency tree at the end of the migration process will look like this: - Commons depends on a minimal set of external libraries (probably only Jakarta Commons IO and JAXP) - Batik depends only on Commons, not on FOP. - FOP depends on Commons and only optionally on Batik for SVG functionality. That should eliminate most dependency problems we suffer from today. The rest is mostly talking to each other. The big problem with this whole problem is resources. I'm doing my part in this on my own time which is limited. I don't think the Batik committers have lots of free time to move on quickly here. So, if you want to help unwinding the whole thing, you're most welcome. You're still a committer in FOP (and therefore in Commons) and you can always request write access to the repository (yours got removed during the switch to SVN). Concerning your comments on the build files: I usually work with SVN checkouts in Eclipse (FOP referencing the Batik project and not the JAR file in the lib directory, and not using Ant to build inside the IDE). Compatibility is verified by updating the JARs in the lib directory and using the Ant builds from the command-line. I'm happy that way. But that's just how I do it. I suggest we move this whole coordination issue over to the [EMAIL PROTECTED] mailing list. This discussion is not FOP-specific. On 13.04.2006 11:38:27 Peter West wrote: On Wed, 2006-04-12 at 14:07 +0200, Jeremias Maerki wrote: On 12.04.2006 13:55:44 Peter West wrote: snip/ Is there other than accidental co-ordination between commons, batik and fop? Accidental? ATM, no coordination is required for releasing Commons as Batik doesn't use it, yet. The plan for XML Graphics Commons on the Wiki is still valid and provides the base for work on Commons. FOP 0.92 will still use Batik 1.6 as we can redistribute only released JAR files. No snapshot JARs as in the past. Coordination as necessary between subprojects in XML Graphics happens on [EMAIL PROTECTED] What guidance will there be for users in co-ordinating versions of the three? I don't understand the question, sorry. I had drawn the conclusion, falsely it appears, that co-ordination of the three elements was in the offing. Hence the discussion of the stability of trunk code in fop, batik and commons. I don't see how you plan to work the extraction without such co-ordination. It is an aim that the batik guys be able to commit to the transcoders. That impacts on fop. There is a question on the wiki about builds. Individual builds or one über-build? Buzzing around at the back of that question is the larger one of co-ordinating the trees. The wiki mentions that the transcoders can be used in the batik context (and others) independently of fop. However, don't the transcoders get involved in the round-trip when embedded svg elements are rendered by fop to pdf or ps? I don't know, but if so, there's a nice chain of dependency from fop - batik - fop', where fop may not currently equal fop'. The current split of fop and commons has nothing to do with batik, it seems. I was working on the assumption that the creation of commons implied the three-way compatibility of trunk elements. ...a Batik release didn't involve a FOP release until now which is something that must change. At some time in the future. I'm working on a project that uses 0.20.5, batik 1.6 and, now, the fop and batik trunk code. It looks as though I may have to unwind the batik trunk code. It seems to me that the builds of the three trees must at least utilise common build file import elements. Building fop is going to depend upon the availability of particular trunk snapshots of commons and batik. Otherwise, how do you co-ordinate development on the batik and fop and commons trunks? There are users who want release versions only, and there are users who are building from the trunk, including, but not restricted to, the developers. For the latter users, the build process must be able to determine whether the tree of primary focus has access to compatible source trees or jars for the other trees. That seems to imply that each tree maintains a range of compatible versions. Changing fop, say, may then mean updating the build files for commons and batik to reflect the fact that dependencies somewhere have just changed. That, in turn, seems to imply that the
DO NOT REPLY [Bug 39285] - Attempt to render xml with inline image causes java.lang.OutOfMemoryError
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=39285. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=39285 --- Additional Comments From [EMAIL PROTECTED] 2006-04-13 15:07 --- Created an attachment (id=18094) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=18094action=view) xml contains inline images causes out of memory error -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 39285] - Attempt to render xml with inline image causes java.lang.OutOfMemoryError
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=39285. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=39285 --- Additional Comments From [EMAIL PROTECTED] 2006-04-13 15:07 --- Created an attachment (id=18095) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=18095action=view) xml no inline images works fine -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 39307] New: - FOP .bat batch file on WinXP SP2
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=39307. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=39307 Summary: FOP .bat batch file on WinXP SP2 Product: Fop Version: 0.91 Platform: Other URL: http://xmlgraphics.apache.org/fop/ OS/Version: Windows XP Status: NEW Severity: minor Priority: P4 Component: general AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] Batch file didn't work until (a) changed labels to less than 8 characters (per Microsoft recommendation) (b) added a few line returns separating document apart -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
