RE : patch 0.20.5 - releasing memory allocated
I use one page sequence with lots and large tables I don't mesure memory consumption but the speed (I would do it the next week with jprobe) After download cvs branch fop-0_20_2-maintain I must execute build.bat, That's all ? which java source were modified ? -Message d'origine- De : J.Pietschmann [mailto:[EMAIL PROTECTED] Envoyé : mercredi 3 mars 2004 22:17 À : [EMAIL PROTECTED] Objet : Re: patch 0.20.5 - releasing memory allocated Philippe PITHON wrote: In forum, I see a message There was a patch afterwards for releasing memory allocated by the table layout to this branch after the release I have download the head of the fop-0_20_2-maintain branch and build FOP But, but after many tests, I dont see a difference in speed or less place memory Unless you use lots and/or large tables without enclosing them in small page sequences, you wont see much of a speed increase or less memory consumption (how do you measure memory consumption anyway?) J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fop generates cryptic font name
Hello everyone, I'm using fop 0.20.5 to create PDFs with embedded fonts. I generated the metrics files with fop and they look like this: font-metrics type=TYPE0 font-nameArialNarrow/font-name embed/ ... However, fop generates this in my PDFs: 8 0 obj /Type /FontDescriptor /FontName /2Ebbf7ArialNarrow As you can see, there are a number of cryptic characters before the font name. Unfortunately, every time I re-run my program, these characters are different. This leads to a situation, where we have 1000 documents with (supposedly) 1000 different fonts, so the RIP continually re-generates the font, because it thinks it is a new one. This slows output down considerably. So, where does that prefix come from and how can I avoid it? Thanks in advance for any pointers, Ulrich - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Fop generates cryptic font name
As far as I know this is correct. This ensures that the font embedded in the PDF document is always used, With no risk for collision with eventual fonts with the same name installed on the system that runs the PDF. Regards, Dennis JD Myrén Developer Oslo Kodebureau Tel: (+47) 98 00 11 92 Mail: [EMAIL PROTECTED] Web: www.oslokb.no -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Ulrich Mayring Sent: 4. mars 2004 10:38 To: [EMAIL PROTECTED] Subject: Fop generates cryptic font name Hello everyone, I'm using fop 0.20.5 to create PDFs with embedded fonts. I generated the metrics files with fop and they look like this: font-metrics type=TYPE0 font-nameArialNarrow/font-name embed/ ... However, fop generates this in my PDFs: 8 0 obj /Type /FontDescriptor /FontName /2Ebbf7ArialNarrow As you can see, there are a number of cryptic characters before the font name. Unfortunately, every time I re-run my program, these characters are different. This leads to a situation, where we have 1000 documents with (supposedly) 1000 different fonts, so the RIP continually re-generates the font, because it thinks it is a new one. This slows output down considerably. So, where does that prefix come from and how can I avoid it? Thanks in advance for any pointers, Ulrich - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fop generates cryptic font name
Dennis Myrén wrote: As far as I know this is correct. This ensures that the font embedded in the PDF document is always used, With no risk for collision with eventual fonts with the same name installed on the system that runs the PDF. Ok, what you say makes sense. But is there a way to turn this behavior off in selected cases? Ulrich - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Fop generates cryptic font name
I don't think so, at least not without hacking FOP. And the PDF specification highly recommends doing these six characters in front of the font name. Regards, Dennis JD Myrén Developer Oslo Kodebureau Tel: (+47) 98 00 11 92 Mail: [EMAIL PROTECTED] Web: www.oslokb.no -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Ulrich Mayring Sent: 4. mars 2004 11:24 To: [EMAIL PROTECTED] Subject: Re: Fop generates cryptic font name Dennis Myrén wrote: As far as I know this is correct. This ensures that the font embedded in the PDF document is always used, With no risk for collision with eventual fonts with the same name installed on the system that runs the PDF. Ok, what you say makes sense. But is there a way to turn this behavior off in selected cases? Ulrich - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fop generates cryptic font name
Dennis Myrén wrote: And the PDF specification highly recommends doing these six characters in front of the font name. It does? Do you have a reference where? I looked through it, but didn't find any mention of these six characters. thanks again, Ulrich - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Fop generates cryptic font name
Chapter 5.5.3 - Font Subsets mentions this. Regards, Dennis JD Myrén Developer Oslo Kodebureau Tel: (+47) 98 00 11 92 Mail: [EMAIL PROTECTED] Web: www.oslokb.no -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Ulrich Mayring Sent: 4. mars 2004 11:46 To: [EMAIL PROTECTED] Subject: Re: Fop generates cryptic font name Dennis Myrén wrote: And the PDF specification highly recommends doing these six characters in front of the font name. It does? Do you have a reference where? I looked through it, but didn't find any mention of these six characters. thanks again, Ulrich - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fop generates cryptic font name
Dennis Myrén wrote: Chapter 5.5.3 - Font Subsets mentions this. Yes, I saw that, but that only refers to font subsets, which have six character and a + sign. However, fop always generates the six characters, even for non-subsetted fonts: /FontName /2Ebbf7ArialNarrow As you can see, there's no + character. Now, I do see the value in using the six characters in any situation, I just need some ammunition for management. If I can prove that it's part of the spec, they'll probably let it fly. As it is, our print shop claims that RIP times have increased significantly because of that. Anyway, thanks a lot for the information, Ulrich - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Fop generates cryptic font name
Tell them that's how Adobe Illustrator is doing it. Regards, Dennis JD Myrén Developer Oslo Kodebureau Tel: (+47) 98 00 11 92 Mail: [EMAIL PROTECTED] Web: www.oslokb.no -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Ulrich Mayring Sent: 4. mars 2004 12:09 To: [EMAIL PROTECTED] Subject: Re: Fop generates cryptic font name Dennis Myrén wrote: Chapter 5.5.3 - Font Subsets mentions this. Yes, I saw that, but that only refers to font subsets, which have six character and a + sign. However, fop always generates the six characters, even for non-subsetted fonts: /FontName /2Ebbf7ArialNarrow As you can see, there's no + character. Now, I do see the value in using the six characters in any situation, I just need some ammunition for management. If I can prove that it's part of the spec, they'll probably let it fly. As it is, our print shop claims that RIP times have increased significantly because of that. Anyway, thanks a lot for the information, Ulrich - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: space after fo:instream-foreign-object/svg:line
Tuna Vardar wrote: snip/ I'm using FOP 0.20.5 and Batik 1.5beta4. How can I clear away the space between two tables? tables are block level elements, the formatter will try to place a new block level element onto a new line. The space allowed for each line can be controlled by setting the line-height property. I'm not sure what you are trying to achieve, why are you using SVG to just draw a line. Will borders on the table themselves not satisfy this requirement? Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: space after fo:instream-foreign-object/svg:line
I'm not sure what you are trying to achieve, why are you using SVG to just draw a line. Will borders on the table themselves not satisfy this requirement? setting border-bottom=solid black attr. in fo:table helped me to get what I need. Thanks for your help. BR, tuna - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE : patch 0.20.5 - releasing memory allocated
Philippe PITHON wrote: After download cvs branch fop-0_20_2-maintain I must execute build.bat, That's all ? Basically yes. which java source were modified ? Various table related files. If you can render the document with 0.20.5, a noticable speedup occurs only if the memory is nearly exhausted. The patch is more for people who got an OutOfMemoryException. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]