Kerning
Started a new thread on the Kerning topic here as the old subject line was inappropriate. On Tue, 6 Dec 2005 12:15 am, Luca Furini wrote: Manuel Mall wrote: I wonder if the same argument does apply to kerning as well? The moment you change font-size, text-decoration, background-color, alignment and the like, which is what fo:inline is mainly for, you create a barrier with respect kerning. Or to put it differently, I believe kerning applies only to like characters, same as glyph merging. Not sure here: if we want to use kerning between, for example, VA I think it would be even more desirable to use it if the V has a bigger font size, or the A a smaller one; it could maybe need some heuristic to handle a kerning between character with different sizes, but I think it would be a desirable feature. There seem to be different kerning algorithms around. The simplistic approach seems to be to use the kerning information stored in the font. That information can only be applied to characters with the same font size. And yes it does suffer from the problem you mentioned above. Typesetting programs may provide additional kerning algorithms (apart from allow the user to manually adjusting kerning). For example Adobe InDesign has something like optical kerning where the kerning information is calculated based on the shape of adjacent characters. I would think something like that would be outside the scope of FOP. In the end XSL-FO has the letter-spacing property which users (and programs generating XSL-FO) can use to adjust kerning. Nonetheless, I agree that the think may become strange with different backgrounds or vertical alignments ... maybe we should define which properties break a kerning pair ... IMO FOP should limit itself to: a) Use kerning only for consecutive characters within the same fo b) Limit itself to the kerning information in the font c) Only apply kerning if the letter-spacing property has the value normal (and the font supports it) Regards Luca Cheers Manuel
Re: PNG renderer not closing output streams properly.
Thanks for spotting that one. I've just fixed it in Subversion:
http://svn.apache.org/viewcvs?rev=354537view=rev
On 04.12.2005 15:35:50 Amin Ahmad wrote:
Hi Team FOP,
I was playing around with the PNG Renderer, and I think I noticed a problem
-- when it produces multiple files (one per page) it does not appear to be
explicity closing the files it creates. Java GC takes care of closing the
files automatically, but, running Java 5, the final file is left open until
the JVM terminates.
In the code below from PNGRenderer, on the last line of the for loop, the
output stream is flushed but never closed. At the top of the loop, os is
reassigned to a new output stream for the next page.
thanks,
Amin
public void stopRenderer() throws IOException {
super.stopRenderer();
for (int i = 0; i pageViewportList.size(); i++) {
OutputStream os = getCurrentOutputStream(i);
if (os == null) {
log.warn(No filename information available.
+ Stopping early after the first page.);
break;
}
// Do the rendering: get the image for this page
RenderedImage image = (RenderedImage)
getPageImage((PageViewport) pageViewportList
.get(i));
// Encode this image
log.debug(Encoding page + (i + 1));
renderParams = PNGEncodeParam.getDefaultEncodeParam(image);
// Set resolution
float pixSzMM = userAgent.getPixelUnitToMillimeter();
// num Pixs in 1 Meter
int numPix = (int)((1000 / pixSzMM) + 0.5);
renderParams.setPhysicalDimension(numPix, numPix, 1); // 1 means
'pix/meter'
// Encode PNG image
PNGImageEncoder encoder = new PNGImageEncoder(os, renderParams);
encoder.encode(image);
os.flush();
}
}
Jeremias Maerki
DO NOT REPLY [Bug 37813] New: - span property causes random insertion of page breaks
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=37813. 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=37813 Summary: span property causes random insertion of page breaks Product: Fop Version: 0.90 Platform: Other URL: http://xml.apache.org/fop OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: pdf AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] If I create three blocks on a page and make the first and third set to span=all, a page break will be added. This pattern will continue for as many alternating blocks as I include. I need to create a heading that SPANS two columns, followed by some text IN columns, repeated. It works fine for the first two fo:blocks, but after that it begins added page breaks in weird places. Also, this behavior will occur even with column-count=1 instead of 2. The problem starts with the second fo:block span=all element. I tried to fix this by using multiple region-body elements, but it failed. Code below... ?xml version=1.0 encoding=UTF-8? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; xmlns:r=http://xmlresume.sourceforge.net/resume/0.0; fo:layout-master-set fo:simple-page-master page-width=8.5in page-height=11in master-name=resume-page fo:region-body column-count=2/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=resume-page fo:flow flow-name=xsl-region-body line-height=normal fo:block span=allTest Spanned Block/fo:block fo:block span=noneTest Unspanned Block Test Unspanned Block Test Unspanned Block Test Unspanned Block/fo:block !-- this one causes the error -- fo:block span=allTest Spanned Block/fo:block !-- this one doesn't -- !-- fo:block span=noneTest Spanned Block/fo:block -- /fo:flow /fo:page-sequence /fo:root !-- Failed Solution ?xml version=1.0 encoding=UTF-8? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; xmlns:r=http://xmlresume.sourceforge.net/resume/0.0; fo:layout-master-set fo:simple-page-master page-width=8.5in page-height=11in master-name=resume-page-A fo:region-body/ /fo:simple-page-master fo:simple-page-master page-width=8.5in page-height=11in master-name=resume-page-B fo:region-body column-count=2/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=resume-page-A fo:flow flow-name=xsl-region-body line-height=normal fo:blockTest Spanned Block/fo:block /fo:flow /fo:page-sequence fo:page-sequence master-reference=resume-page-B fo:flow flow-name=xsl-region-body line-height=normal fo:blockTest Unspanned Block Test Unspanned Block Test Unspanned Block Test Unspanned Block/fo:block /fo:flow /fo:page-sequence fo:page-sequence master-reference=resume-page-A fo:flow flow-name=xsl-region-body line-height=normal fo:blockTest Spanned Block/fo:block /fo:flow /fo:page-sequence /fo:root -- -- 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 37815] New: - Graphic scaling scale-to-fit Not working as expected
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=37815. 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=37815 Summary: Graphic scaling scale-to-fit Not working as expected Product: Fop Version: 1.0dev Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: images AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] When scaling an external graphic using fo:external-graphic src=file:../graphics/ltcwidth.jpg width=100% content-width=scale-to-fit content-height=100%/ So that graphics that are too wide are scaled down but graphics that fit remain unscaled it does not operate as expected. Graphics that are too wide are invalidated Graphics the should not be scaled are streched to fit the width only. -- 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 37815] - Graphic scaling scale-to-fit Not working as expected
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=37815. 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=37815 --- Additional Comments From [EMAIL PROTECTED] 2005-12-07 05:00 --- Created an attachment (id=17164) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=17164action=view) Pdf showing the output -- 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 37815] - Graphic scaling scale-to-fit Not working as expected
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=37815. 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=37815 --- Additional Comments From [EMAIL PROTECTED] 2005-12-07 05:05 --- The fopbugeg.zip attached file contains an example that shows how it fails this example is an edited version of the images.fo example in the source tree. It is archived so that the images are in the same relative path as they were originaly. The before.pdf attached file shows the output as is generated with the current version. -- 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 37815] - Graphic scaling scale-to-fit Not working as expected
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=37815. 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=37815 --- Additional Comments From [EMAIL PROTECTED] 2005-12-07 05:15 --- Created an attachment (id=17166) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=17166action=view) [PATCH] fixes the problem The issue seems to be caused by a lack of a cast before an integer divide is assigned to a double eg. double rat1 = cwidth / fobj.getIntrinsicWidth(); where both cwidth and the returned value are integers. Adding a double cast to the cwidth seems to fix the problem eg. double rat1 = (double) cwidth / fobj.getIntrinsicWidth(); The submited patch fixes this problem I am no JAVA expert so I don't know if this is specific to the implementation of JAVA I am running which is 1.5.0_05-b05 after.pdf shows the output after the patch is applied which is as I expect it to be Hope this helps and thanks to the development for all their good work -- 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.
