Re: DO NOT REPLY [Bug 48575] New: When generating EPS from SVG image content doesn't fit borders
Hi Paul,
I am a little unclear what the problem is here. I rendered your svg and
produced the attached eps an pdf to compare. They both look the same to
me. Can you elaborate on the problem with reference to my attached images,
please?
Thanks,
Peter
On Tue, Jan 19, 2010 at 8:39 PM, bugzi...@apache.org wrote:
https://issues.apache.org/bugzilla/show_bug.cgi?id=48575
Summary: When generating EPS from SVG image content doesn't fit
borders
Product: Fop
Version: 0.95
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: ps
AssignedTo: fop-dev@xmlgraphics.apache.org
ReportedBy: paul.ly...@gmail.com
org.apache.fop.render.ps.EPSTranscoder produces EPS file from SVG DOM, and
image content doesn't fit image borders (so that picture is croped), though
viewBox parameter in svg file covers all content.
If specify area of interest (by EPSTranscoder.KEY_AOI hint) aproximately
1.38
times larger then actual viewBox then content fit borders well.
Versions 0.93 and 0.94 generate EPS file well, image content fits borders
as it
should.
Batik 1.7 was used to create SVG DOM.
Code being used for conversion:
public static byte[] serialize2EPS(Document document){
ByteArrayOutputStream baos = new ByteArrayOutputStream();
EPSTranscoder tr = new EPSTranscoder();
try {
tr.transcode(new TranscoderInput(document),new
TranscoderOutput(baos));
} catch (TranscoderException e) {
e.printStackTrace();
}
return baos.toByteArray();
}
SVG file being processed:
?xml version=1.0?
svg transform=scale(1.0)
width=100.0mm xmlns:xlink=http://www.w3.org/1999/xlink;
height=100.0mm
viewBox=0.0 0.0 100.0 100.0 xmlns=http://www.w3.org/2000/svg;
rect fill=#ff x=0 width=100.0 height=100.0 y=0
style=stroke:#ff/
path stroke-linecap=square fill-opacity=1.0 fill=none
fill-rule=nonzero stroke-linejoin=miter style=stroke:#000
d=M48.913043478260875,13.539282990083906
C64.97395582555245,13.539282990083906
77.99389778794813,20.881676490189015 77.99389778794813,29.938977879481314
C77.99389778794813,38.99627926877361 64.97395582555245,46.33867276887872
48.913043478260875,46.33867276887872 C32.852131130969305,46.33867276887872
19.83218916857361,38.99627926877361 19.83218916857361,29.938977879481314
C19.83218916857361,20.881676490189015 32.852131130969305,13.539282990083906
48.913043478260875,13.539282990083906Z
stroke-width=0.1 stroke-opacity=1.0 stroke-miterlimit=1.0/
path stroke-linecap=square fill-opacity=1.0 fill=none
fill-rule=nonzero stroke-linejoin=miter style=stroke:#000
d=M1.0526315789473684,1.4736842105263157
C1.0526315789473684,1.4736842105263157 98.73684210526316,1.4736842105263157
98.73684210526316,1.4736842105263157 C98.73684210526316,1.4736842105263157
98.73684210526316,98.52631578947368 98.73684210526316,98.52631578947368
C98.73684210526316,98.52631578947368 1.0526315789473684,98.52631578947368
1.0526315789473684,98.52631578947368 C1.0526315789473684,98.52631578947368
1.0526315789473684,1.4736842105263157
1.0526315789473684,1.4736842105263157Z
stroke-width=0.1 stroke-opacity=1.0 stroke-miterlimit=1.0/path
stroke-linecap=square fill-opacity=1.0 fill=none fill-rule=nonzero
stroke-linejoin=miter style=stroke:#000
d=M5.684210526315789,5.473684210526316
C5.684210526315789,5.473684210526316
86.52631578947368,90.52631578947368 86.52631578947368,90.52631578947368
stroke-width=0.1 stroke-opacity=1.0 stroke-miterlimit=1.0/path
stroke-linecap=square fill-opacity=1.0 fill=none fill-rule=nonzero
stroke-linejoin=miter style=stroke:#000
d=M6.105263157894737,89.6842105263158 C6.105263157894737,89.6842105263158
93.89473684210526,6.736842105263165 93.89473684210526,6.736842105263165
stroke-width=0.1 stroke-opacity=1.0 stroke-miterlimit=1.0//svg
--
Configure bugmail:
https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
out.eps
Description: PostScript document
out.pdf
Description: Adobe PDF document
DO NOT REPLY [Bug 48575] When generating EPS from SVG image content doesn't fit borders
https://issues.apache.org/bugzilla/show_bug.cgi?id=48575 --- Comment #2 from Peter Hancock peter.hanc...@gmail.com 2010-01-20 03:23:32 UTC --- Created an attachment (id=24864) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=24864) Rendered pdf -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48575] When generating EPS from SVG image content doesn't fit borders
https://issues.apache.org/bugzilla/show_bug.cgi?id=48575 --- Comment #3 from Peter Hancock peter.hanc...@gmail.com 2010-01-20 03:23:50 UTC --- Hi Paul, I am a little unclear what the problem is here. I rendered your svg and produced the attached eps an pdf to compare. They both look the same to me. Can you elaborate on the problem with reference to my attached images, please? Peter -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48567] Implementation of support for double-byte fonts by AFP renderer.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48567 --- Comment #3 from Jeremias Maerki jerem...@apache.org 2010-01-20 07:30:29 UTC --- Peter, I've taken a peek at your code. Eclipse had a bit of trouble applying the patch because you renamed AFPFontReader to CharacterSetBuilder, but that was not insurmountable. From the functionality POV I guess this works fine. At least I get nicely formatted Japanese text which seems to be consistent with PDF output generated with Arial Unicode MS. You've asked me off-list if it is correct to get the em space width from the FNO field rather than the FNC field. But I don't see any information on the em space in the FNC field. At any rate, FNO is the right place to get this from IMO. While going through your changes I wondered if it would not have made sense to extract the em space in every case, not just in the double-byte case. That could have reduced the code duplication a bit that is caused by org.apache.fop.afp.fonts.CharacterSetBuilder.DoubleByteLoader. At least the processFontOrientation() method looks like unnecessary code duplication to me. Furthermore, it is a bit strange that you call this unitPerEm in CharacterSetOrientation what is actually the em space increment. Maybe that's what you confused in FNC with. There's a unit per em there but that has a different purpose. I'm wondering if you would agree that using Type 0 (or CIDKeyed) instead of double-byte is a more accurate choice for the font type in the user configuration. Do you think that the fallback character business in the configuration is really necessary? I fear that this is too complicated for users. I don't quite see what it would help. Can you explain why you added this? A few observations while looking into this (not related to your work): - Some of the AFP viewers to quite some time to display the files with the embedded Japanese font, the Papyrus Client being the exception. Maybe that is just so. At least there doesn't seem to be anything technically wrong. - The restriction of the font and codepage names to exactly 8 characters is something we should relax eventually (by creating actual FullyQualifiedNameTriplet instances in MapCodedFont). Probably a remainder from the times where the triplets were not encapsulated in classes. At least there is no such restriction in the AFP specs. If you don't have anything else that you need to address with this patch, I could commit it later this week. I'd like your feedback on my comments above before I do that. I could handle the few changes myself. Since I've already made some local, cosmetic changes locally, that would save my applying the patch a second time. However, if you could update the documentation for the website once we've finalized the above, that'd be appreciated. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48567] Implementation of support for double-byte fonts by AFP renderer.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48567 --- Comment #4 from Peter Hancock peter.hanc...@gmail.com 2010-01-20 08:55:17 UTC --- (In reply to comment #3) Peter, I've taken a peek at your code. Thanks for reviewing the patch so quicky! Eclipse had a bit of trouble applying the patch because you renamed AFPFontReader to CharacterSetBuilder, but that was not insurmountable. Sorry about that! You've asked me off-list if it is correct to get the em space width from the FNO field rather than the FNC field. But I don't see any information on the em space in the FNC field. At any rate, FNO is the right place to get this from IMO. Furthermore, it is a bit strange that you call this unitPerEm in CharacterSetOrientation what is actually the em space increment. Maybe that's what you confused in FNC with. There's a unit per em there but that has a different purpose. I was unsure if there was a distinction between 'em space increment' and 'units per em' - now I know. While going through your changes I wondered if it would not have made sense to extract the em space in every case, not just in the double-byte case. That could have reduced the code duplication a bit that is caused by org.apache.fop.afp.fonts.CharacterSetBuilder.DoubleByteLoader. At least the processFontOrientation() method looks like unnecessary code duplication to me. That makes sense - we can remove the now redundant CharacterSetOrientation(int) constructor as well. I'm wondering if you would agree that using Type 0 (or CIDKeyed) instead of double-byte is a more accurate choice for the font type in the user configuration. CIDKeyed then? Do you think that the fallback character business in the configuration is really necessary? I fear that this is too complicated for users. I don't quite see what it would help. Can you explain why you added this? using a fallback character was my first approach and the em space, as recommended by yourself, my second. In retrospect I now totally agree that the fallback character is probably useless and certainly reduces usability. - The restriction of the font and codepage names to exactly 8 characters is something we should relax eventually (by creating actual FullyQualifiedNameTriplet instances in MapCodedFont). Probably a remainder from the times where the triplets were not encapsulated in classes. At least there is no such restriction in the AFP specs. I am looking at this now. I thought it may have been an AFP restriction since I seemed to get a badly formed AFP when I forced through a name of length 6. This will have to be resolved at a later time I guess. If you don't have anything else that you need to address with this patch, I could commit it later this week. I'd like your feedback on my comments above before I do that. I could handle the few changes myself. Since I've already made some local, cosmetic changes locally, that would save my applying the patch a second time. I agree with all of your suggestions. Before you go ahead and commit I wonder how easy it is to configure fop to not embed the font. Is much dev work required do you think? In http://xmlgraphics.apache.org/fop/trunk/fonts.html it is claimed that not supplying an embed-url attribute directs fop not to embed the font, but this is not so, and in fact, fop never seems to have a chance at setting the embeddable flag on an AFP font. When AFPRendererConfigurator constructs the font instance it could set the flag then based on an attribute, but what other information is needed? When I manually set embeddable to false the rendered AFP only declares the font resource and the code page in the MCF structured field. I have not tried printing yet (Our afp printer is playing up for me today) or checked the spec to see if this is ok. If you happen to know that it should work we could perhaps add a boolean-like attribute to the font attribute (respected when type=CIDKeyed or all AFP?) and call AFPFont.setEmbeddable() upon creation (or pass a constructor arg). Otherwise I guess this would be a future unit work. However, if you could update the documentation for the website once we've finalized the above, that'd be appreciated. I will attach this as a second patch to this bug. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
