DO NOT REPLY [Bug 44358] - OufOfMem

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=44358





--- Additional Comments From [EMAIL PROTECTED]  2008-02-14 15:12 ---

Small update:
I've been browsing around, and may have found the possible cause of the arrays 
not being collected.
Theoretically, it is possible that an implementation of a tracing GC algorithm 
would still view the arrays 
as reachable if their first element is still strongly reachable... Since this 
is the default absolute-position 
property, and it is possibly referenced by a significant amount of FObjs.

Maybe you could try something like:
* add an empty protected cleanup() method to org.apache.fop.fo.PropertyList
* add an override for this method to StaticPropertyList, and explicitly null 
out the first element of the 
member arrays
* in FOTreeBuilder.MainFOHandler.endElement(), inside the if-block right after 
currentFObj.endOfNode(), add currentPropertyList.cleanup() as a first line



-- 
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 44422] - space-after not honored on blocks in table-header

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=44422


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2008-02-14 10:52 ---
Hi Sean,

It's FOP 0.20.5 that is at fault here. The space-after on the block is
conditional and table-cell generates a reference area, so the space must be
discarded. See http://www.w3.org/TR/xsl11/#spacecond

To keep the space you must add the property space-after.conditionality="retain"
on the block.

HTH,
Vincent

-- 
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 44412] - Missing border-after when break-after set on a block

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=44412





--- Additional Comments From [EMAIL PROTECTED]  2008-02-14 10:35 ---
Created an attachment (id=21531)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=21531&action=view)
Missing border-before when break-before set

Another problematic situation: when break-before is set on a block, the before
border of the enclosing block is not rendered.

-- 
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 44422] - space-after not honored on blocks in table-header

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=44422





--- Additional Comments From [EMAIL PROTECTED]  2008-02-14 10:31 ---
Created an attachment (id=21530)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=21530&action=view)
Example of space-after not working in FOP Trunk


-- 
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 44422] - space-after not honored on blocks in table-header

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=44422





--- Additional Comments From [EMAIL PROTECTED]  2008-02-14 10:31 ---
Created an attachment (id=21529)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=21529&action=view)
Example of space-after working in FOP 0.20.5


-- 
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 44422] New: - space-after not honored on blocks in table-header

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=44422

   Summary: space-after not honored on blocks in table-header
   Product: Fop
   Version: 0.94
  Platform: PC
OS/Version: Windows Vista
Status: NEW
  Severity: normal
  Priority: P2
 Component: general
AssignedTo: fop-dev@xmlgraphics.apache.org
ReportedBy: [EMAIL PROTECTED]


I've been monitoring this issue throughout the past few FOP releases, and it
doesn't appear to be fixed yet nor can I find a bug report on it.  This works in
0.20.5 but not in 0.94 or even trunk.

The space-after property on blocks inside a table-header do not work. 
Padding-after does.

Modifying the table.fo example file to have a table-header with a space-after
block will easily recreate the issue:


  
  
  
  

  
Table Header
  

  
  

  good
  bad
  ugly

  


I will attach output from 0.20.5 and output from trunk.

-- 
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: Supporting unusual encodings for Type 1 fonts

[The Web Maestro]

In addition to Acrobat 6,7,8,+, Apple QuickView & Evince, I would
think nice to have:
- Acrobat Reader 5 (last version for Mac OS 9 Classic)
- Apple Preview 10.4 (probably similar to QuickView)
- Preview for 10.3 (Panther) would be nice too...

Is it possible the PDF code for option 1 could be 'cleaned up' in the
future (or does it matter)?

Clay



On 2/13/08, Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> Just some details what each approach will produce:
>
> #1 produces a /CIDFontType0 CIDFont [1] and a /Type0 Composite Font
> referencing the former.
>
> #2 produces one or more /Type1 fonts.
>
> [1] for TrueType we produce a CIDFontType2 CIDFont and a /Type0
> Composite font for each TrueType font. OpenOffice produces one or more
> /TrueType fonts for each TrueType font.
>
> #1 would always generate a CID font for simplicity. What you propose is
> basically a "#2a", i.e. produce a /Type1 font if the document stays
> within the default encoding of the font. If additional characters are
> used FOP would switch to CID fonts instead of producing a /Type1 font.
> So this needs elements from #1 and #2. Possible and probably makes sense
> if CID fonts work in the first place. I like it.
>
> BTW, I just found out that I have to generate a ToUnicode CMap if a
> Type1 font doesn't use one of the encodings that are predefined in the
> PDF spec. So a little more work for me there.
>
> On 13.02.2008 11:57:34 Vincent Hennebert wrote:
> > Hi Jeremias,
> >
> > With solution #1, if I happen to use only the glyphs from the font that
> > are available in its default encoding, will the resulting PDF be the
> > same as in solution #2?
> > What I mean is, will feature-incomplete PDF readers be able to display
> > it? In which case this wouldn't be that bad.
> >
> > Anyway, solution #1 also looks cleaner to me, so go for it. If that
> > means that I'll have to create a RFE for my favourite PDF reader, then
> > I'll do it ;-)
> >
> > Vincent
> >
> >
> > Jeremias Maerki wrote:
> > > I've been asked to look into the possibility to support unusual
> > > encodings (like Cyrillic) with Type 1 fonts. Right now we only support
> > > WinAnsiEncoding (plus special handling for Symbol and ZapfDingbats).
> > >
> > > I already have an AFM parser. The AFM parser is the precondition to
> > > safely support non-standard encodings as only this file contains the
> > > glyph list of a font.
> > >
> > > I'm now on a good way to support non-WinAnsi encodings since I can now
> > > build CodePointMapping instances from an AFM file. I then have to teach
> > > the PDF and PS renderers to make use of these special encodings.
> > >
> > > That's step 1, but it will only make the font's native encoding
> > > available in FOP. The number of available glyphs for a Type 1 font will
> > > still remain under 255 (typicaly under 223 as the first 32 chars are
> > > usually not used). To support all glyphs of a Type 1 font we need more
> > > and I found two possible ways to pursue:
> > >
> > > 1. Treat Type 1 fonts as CID fonts.
> > >
> > > + Probably the cleaner approach.
> > > + All glyphs are supported under one single font (no font renderer-level
> > >   font switching required, see below)
> > > - Makes the generated PDF/PS code a little less readable but that's not
> > >   important.
> > >
> > > 2. Do something like OpenOffice when handling fonts with more than 255
> > > chars: Create multiple single-byte encodings which map to the same base
> > > font. This will require an 1:n relationship from font to char mapping
> > > which the renderers also have to handle. The first encoding will be
> > > equal to the font's default encoding (PDF calls that the "implicit base
> > > encoding"). The other encoding(s) will be built from the rest of the
> > > available characters. In the renderer it will be necessary to switch
> > > fonts from one character to another (not the same as switching from
> > > Helvetica to Symbol, i.e. not at FO level, but at renderer level).
> > >
> > > + Higher compatibility with PDF viewers which are not yet
> > >   feature-complete.
> > > + Keeps the generated PDF/PS code more readable (not important)
> > > - Switching between derived fonts (i.e. font with a common base font but
> > >   with special encodings) is necessary. SingleByteFont needs to be split
> > >   in two classes.
> > >
> > > An example: The "Baskerville Cyrillic" font contains 264
> > > characters/glyphs. The default encoding only contains 221 characters. So
> > > 43 additional characters can be made available like this.
> > >
> > > I'm currently leaning towards CID fonts as it is probably the cleaner
> > > approach. Both solutions are probably pretty much the same in terms of
> > > effort. The CID approach will take more work in the PS renderer and the
> > > multi-encoding approach will make changes necessary in FOP's font
> > > library.
> > >
> > > If anyone has thoughts on this, I'd appreciate it. I'll finish the
> > > changes for supporting the default encodings and then

Re: Remove deprecated methods in outer API for 0.95?

[The Web Maestro]

+1 to remove pre-0.94 deprecated methods & stuff.

Clay



On 2/14/08, Max Berger <[EMAIL PROTECTED]> wrote:
> >  >For some time now we have a number of methods in our outer API that are
> >  >deprecated. I think we should remove them now. Anyone against my doing
> >  >that as part of the preparations for the release?
>
> AFAIK it is good practice to keep a deprecated API for at least 1
> release, so I'd say +1 for anything that has been marked deprecated in
> the 0.94 release and earlier.
>
> Max
>

-- 
Sent from Gmail for mobile | mobile.google.com

Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - 
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Remove deprecated methods in outer API for 0.95?

[Chris Bowditch]

Jeremias Maerki wrote:

For some time now we have a number of methods in our outer API that are
deprecated. I think we should remove them now. Anyone against my doing
that as part of the preparations for the release?


+1

Chris

Re: svn commit: r627719 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fo/expr/ fo/properties/ render/afp/fonts/ render/rtf/

[Vincent Hennebert]

andreas.delmelle wrote:
>> - Oorspronkelijk bericht -
>> Van: maxberger 
> 
>> URL: http://svn.apache.org/viewvc?rev=627719&view=rev
>> Log:
>> Created Constants for unit descriptions
> 
> Good idea, Max!

+1 ;-)

Vincent

-- 
Vincent HennebertAnyware Technologies
http://people.apache.org/~vhennebert http://www.anyware-tech.com
Apache FOP Committer FOP Development/Consulting

Re: svn commit: r627719 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fo/expr/ fo/properties/ render/afp/fonts/ render/rtf/

[andreas . delmelle]

>- Oorspronkelijk bericht -
>Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]

>URL: http://svn.apache.org/viewvc?rev=627719&view=rev
>Log:
>Created Constants for unit descriptions

Good idea, Max!

Cheers

Andreas

Re: Remove deprecated methods in outer API for 0.95?

[Vincent Hennebert]

No problem, +1.

Jeremias Maerki wrote:
> For some time now we have a number of methods in our outer API that are
> deprecated. I think we should remove them now. Anyone against my doing
> that as part of the preparations for the release?
> 
> Jeremias Maerki
> 

-- 
Vincent HennebertAnyware Technologies
http://people.apache.org/~vhennebert http://www.anyware-tech.com
Apache FOP Committer FOP Development/Consulting

Re: Remove deprecated methods in outer API for 0.95?

[Max Berger]

>  >For some time now we have a number of methods in our outer API that are
>  >deprecated. I think we should remove them now. Anyone against my doing
>  >that as part of the preparations for the release?

AFAIK it is good practice to keep a deprecated API for at least 1
release, so I'd say +1 for anything that has been marked deprecated in
the 0.94 release and earlier.

Max

Re: Remove deprecated methods in outer API for 0.95?

[andreas . delmelle]

>- Oorspronkelijk bericht -
>Van: Jeremias Maerki [mailto:[EMAIL PROTECTED]
>
>For some time now we have a number of methods in our outer API that are
>deprecated. I think we should remove them now. Anyone against my doing
>that as part of the preparations for the release?

Absolutely no objection from me: +1

Cheers

Andreas

Re: Supporting unusual encodings for Type 1 fonts

[Jeremias Maerki]

False alarm. JPedal and kpdf, for example, have no problems
reconstructing the correct text based on the embedded Encoding. PDFBox,
too, but that one had problems extracting from text written using a
TrueType font. But Adobe Acrobat Reader does have a problem: text
written in a Cyrillic Type 1 font is extracted incorrectly. Not even
adding a ToUnicode CMap helped here. Probably a bug. I have no other
idea who I could help Acrobat extract the text correctly. So, if you
care about copy/paste from Acrobat, switch to TrueType fonts instead of
using fonts with encodings other than AdobeStandardEncoding or
WinAnsiEncoding.

On 13.02.2008 12:12:59 Jeremias Maerki wrote:

> BTW, I just found out that I have to generate a ToUnicode CMap if a
> Type1 font doesn't use one of the encodings that are predefined in the
> PDF spec. So a little more work for me there.




Jeremias Maerki