Re: Tasks - layout

2002-08-22 Thread Keiron Liddle

On Wed, 2002-08-21 at 23:29, Karen Lease wrote: 
 Hi Keiron,
 
 Keiron Liddle wrote:
 
 snip/
  
  The line height calculation and alignment is only very basic at the moment.
  The idea is that the LineLM gets certain information to find the offset to
  baseline and total line height and when the InlineLM add areas they use this
  information to set the position of the inline areas.
  
  
 Yes, I noticed that you'd added this as well to the information returned in the 
BreakPoss.

I worked out some alignment and ipd adjustment things. This look like it
can work in a similar way.
There is one tricky part, the ipd of the text parts accumulate. This means
that to find the total ipd of a line break it needs to add the last ipd
of each layout manager.


 Now that it looks like things are heating up, we probably do need to do 
 some cleanup before we get too much more code written. I agree with 
 Joerg that we could simplify the inheritance now that we are only using 
 the BP stuff. It wouldn't be so much work at this point to fold the BP 
 versions back into the original interface and AbstractLM and to rename 
 LineBP and TextBP. What do you think?

I agree, the BP letters don't really add much information now anyway.

 The other thing I have been thinking about is how to structure the 
 information we are returning in BreakPoss (besides the actual position 
 part). In fact, it's really the same (more or less) information which 
 we'll end up putting on the final Area we create, since a BreakPoss is 
 really just a potential Area. I was wondering a while back whether we 
 should just encapsulate an Area directly in the BreakPoss and use that 
 to store the size information. On the other hand, some information won't 
 be needed on the final areas (once they are positioned) such as the 
 MinOptMax space around the area, the keep constraints etc, which are 
 only used by the LayoutManagers while decided which BreakPoss to 
 actually use to create the Area.

I think this needs to come out from the functionality. If there is too
much on the area tree it will need to cleared at some stage.

 Another general LM issue involves at which level to take into account 
 the stacksize limit. For the inline stuff, I only used it at the LineLM 
 level. I just had the lower level LM return each possible line-end and 
 then let the LineLM decide whether it fit or not. When it got a 
 BreakPoss which was too big, it could then decide to hyphenate, which 
 means going into a kind of mode where it examines less optimal breaks.
 
 The equivalent of that logic on the block stacking level could be to 
 have all block-level LM except the FlowLM return fairly large chunks 
 (between block-level FOs for example) and then have the FlowLM ask them 
 to break the block into smaller pieces when it gets a BreakPoss which 
 overflows the current column size. I was originally thinking of having 
 the block-level LM return on every Line, but that makes a lot of work 
 and a lot of object creation, so it would probably be slow.

I was thinking that it could return a break only if it is better
or the same or if past the end.
This way a block would only have one break position most of the time.




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: Tasks - layout

2002-08-21 Thread Keiron Liddle

Hi Karen, 

On Mon, 2002-08-19 at 23:57, Karen Lease wrote: 
 Hi Keiron etc,
 
 I'm really happy to see all this movement going on and folks from the 
 maintenance branch getting into the redesign to help you out. I'm 
 hoping to be able to start contributing again too, perhaps not right 
 away, but hopefully in September. There may even be some possibility of 
 getting to work on FOP as part of my real work, though it might be 
 hard to work on the new layout in that context. I'll keep the group posted.

Sounds good.

 I'll start by looking at the latest and then maybe cogitating on list or 
 table layout, depending on the timing and what others are interested in 
 doing. It looks like status.xml is the sign-up sheet for the tasks; is 
 that right?

Yes, the status is keeping track of things. 
Which reminds me there are some missing entries for Kevin and Rhett and
some others who are working on certain areas. 

 With regard to the line-height calculations, is anybody in the group 
 interested in getting into the gory details of the baseline stuff for 
 different scripts? I spent some time poring over the spec and trying to 
 get a handle on this, but maybe it's too much detail for now. On the 
 other hand, I'd really like to make sure that this version of FOP 
 handles that stuff correctly as well as being able to do the various 
 kinds of line-stacking strategies defined by the XSL-FO spec.

Plenty of tricky things in that area.

The line height calculation and alignment is only very basic at the moment.
The idea is that the LineLM gets certain information to find the offset to
baseline and total line height and when the InlineLM add areas they use this
information to set the position of the inline areas.

 Regards,
 Karen


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: Tasks - layout

2002-08-21 Thread Tony Graham

Karen Lease wrote at 20 Aug 2002 23:07:46 +0200:
  That would be good. I haven't looked at it for a month or so, but I had 
  (as usual) some questions about various statements in the XSL-FO spec 
  concerning the interpretation of the various properties. Perhaps we 
  could go over those issues at some point.
...
  Arved Sandstrom wrote:
  
  -Original Message-
  From: Karen Lease [mailto:[EMAIL PROTECTED]]
...
  With regard to the line-height calculations, is anybody in the group
  interested in getting into the gory details of the baseline stuff for
  different scripts? I spent some time poring over the spec and trying to
  get a handle on this, but maybe it's too much detail for now. On the
  other hand, I'd really like to make sure that this version of FOP
  handles that stuff correctly as well as being able to do the various
  kinds of line-stacking strategies defined by the XSL-FO spec.
  
   
   I am definitely interested. I have put some thought into these things
   already. Granted, when I implement it'll be a different codebase but I am
   happy to work out the details on this list.

You may be interested in Steve Zilles's statement in the abstract [1]
for his talk at next month's Unicode Conference where he says:

   The extended CSS/XSL model is based on the Open Type font
   model. This model posits a set of alignment baselines for different
   scripts, e.g., alphabetic, ideographic and hanging scripts. This
   allows characters in a given script, but presented in different
   font sizes, to be aligned on the baseline natural to that script.

I just looked in the XSL Recommendation, and Section 7.8.1 notes:

   XSL uses an abstract model of a font. This model is described in
   this section and is based on current font technology as exemplified
   by the OpenType specification [OpenType].

Maybe you also need to look at the OpenType spec.

Regards,


Tony Graham

XML Technology Center - Dublinmailto:[EMAIL PROTECTED]
Sun Microsystems Ireland Ltd   Phone: +353 1 8199708
Hamilton House, East Point Business Park, Dublin 3x(70)19708


[1] http://www.unicode.org/iuc/iuc22/a365.html

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: Tasks - layout

2002-08-21 Thread Karen Lease

Hi Tony,

Thanks for the advice. I have already started to look at the OpenType 
standard, in particular the parts describing the various baselines. 
Unfortunately I don't suppose I'll be attending the Unicode conference 
but perhaps someone here will be and could listen to Steve's talk and 
could report back to the group.

However, it seems clear that FOP will definitely need to enhance the 
information it is managing about Fonts in order to provide the baseline 
information needed to implement these aspects of the spec.

Regards,
Karen

Tony Graham wrote:

 Karen Lease wrote at 20 Aug 2002 23:07:46 +0200:
   That would be good. I haven't looked at it for a month or so, but I had 
   (as usual) some questions about various statements in the XSL-FO spec 
   concerning the interpretation of the various properties. Perhaps we 
   could go over those issues at some point.
 
   Arved Sandstrom wrote:
   
   -Original Message-
   From: Karen Lease [mailto:[EMAIL PROTECTED]]
 
   With regard to the line-height calculations, is anybody in the group
   interested in getting into the gory details of the baseline stuff for
   different scripts? I spent some time poring over the spec and trying to
   get a handle on this, but maybe it's too much detail for now. On the
   other hand, I'd really like to make sure that this version of FOP
   handles that stuff correctly as well as being able to do the various
   kinds of line-stacking strategies defined by the XSL-FO spec.
   

I am definitely interested. I have put some thought into these things
already. Granted, when I implement it'll be a different codebase but I am
happy to work out the details on this list.
 
 You may be interested in Steve Zilles's statement in the abstract [1]
 for his talk at next month's Unicode Conference where he says:
 
The extended CSS/XSL model is based on the Open Type font
model. This model posits a set of alignment baselines for different
scripts, e.g., alphabetic, ideographic and hanging scripts. This
allows characters in a given script, but presented in different
font sizes, to be aligned on the baseline natural to that script.
 
 I just looked in the XSL Recommendation, and Section 7.8.1 notes:
 
XSL uses an abstract model of a font. This model is described in
this section and is based on current font technology as exemplified
by the OpenType specification [OpenType].
 
 Maybe you also need to look at the OpenType spec.
 
 Regards,
 
 
 Tony Graham
 
 XML Technology Center - Dublinmailto:[EMAIL PROTECTED]
 Sun Microsystems Ireland Ltd   Phone: +353 1 8199708
 Hamilton House, East Point Business Park, Dublin 3x(70)19708
 
 
 [1] http://www.unicode.org/iuc/iuc22/a365.html
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, email: [EMAIL PROTECTED]
 
 
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: Tasks - layout

2002-08-21 Thread Karen Lease

Hi Keiron,

Keiron Liddle wrote:

snip/
 
 The line height calculation and alignment is only very basic at the moment.
 The idea is that the LineLM gets certain information to find the offset to
 baseline and total line height and when the InlineLM add areas they use this
 information to set the position of the inline areas.
 
 
Yes, I noticed that you'd added this as well to the information returned in the 
BreakPoss.


Now that it looks like things are heating up, we probably do need to do 
some cleanup before we get too much more code written. I agree with 
Joerg that we could simplify the inheritance now that we are only using 
the BP stuff. It wouldn't be so much work at this point to fold the BP 
versions back into the original interface and AbstractLM and to rename 
LineBP and TextBP. What do you think?

The other thing I have been thinking about is how to structure the 
information we are returning in BreakPoss (besides the actual position 
part). In fact, it's really the same (more or less) information which 
we'll end up putting on the final Area we create, since a BreakPoss is 
really just a potential Area. I was wondering a while back whether we 
should just encapsulate an Area directly in the BreakPoss and use that 
to store the size information. On the other hand, some information won't 
be needed on the final areas (once they are positioned) such as the 
MinOptMax space around the area, the keep constraints etc, which are 
only used by the LayoutManagers while decided which BreakPoss to 
actually use to create the Area.

Another general LM issue involves at which level to take into account 
the stacksize limit. For the inline stuff, I only used it at the LineLM 
level. I just had the lower level LM return each possible line-end and 
then let the LineLM decide whether it fit or not. When it got a 
BreakPoss which was too big, it could then decide to hyphenate, which 
means going into a kind of mode where it examines less optimal breaks.

The equivalent of that logic on the block stacking level could be to 
have all block-level LM except the FlowLM return fairly large chunks 
(between block-level FOs for example) and then have the FlowLM ask them 
to break the block into smaller pieces when it gets a BreakPoss which 
overflows the current column size. I was originally thinking of having 
the block-level LM return on every Line, but that makes a lot of work 
and a lot of object creation, so it would probably be slow.

For tables, I'd be tempted to always have the first layout pass return 
only breaks at row boundaries (or groups of rows linked by spanning 
cells) and only get into row-breaking logic if a) the row doesn't fit 
and there is no previous good break; b) the row and its cells don't 
have keep-together=always.
Of course, if we get a row or a row group which is already starting a 
page and still won't fit, we have to break it anyway (or overflow it) in 
order to avoid the infinite loop problem.

As you and Joerg were discussing the other day, exactly how to do the 
breaking in the row is very complex. If we try to optimize it we will 
get into some very deep decision trees with breaks in each cell.

I tend to think that most tables should be set up to have 
keep-together=always. (Hint to the users!) On the other hand, there are 
cases where people are using tables to get some kind of special layout 
effect (unequal columns for example) and they want the cells to be able 
to be broken, so we can't get around this in the long run.

Regards,
Karen





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: Tasks - layout

2002-08-21 Thread J.Pietschmann

Karen Lease wrote:
 ..., since a BreakPoss is 
 really just a potential Area.

Just nitpicking: It is the state of a LM tree, and in that sense
certainly a bit more than a potential area.

 The equivalent of that logic on the block stacking level could be to 
 have all block-level LM except the FlowLM return fairly large chunks 
 (between block-level FOs for example) and then have the FlowLM ask them 
 to break the block into smaller pieces when it gets a BreakPoss which 
 overflows the current column size. I was originally thinking of having 
 the block-level LM return on every Line, but that makes a lot of work 
 and a lot of object creation, so it would probably be slow.

I'm not sure whether a lot of object creation has to take place.
Anyway, why not pass the stack size to the block and let it return
if it *has* to break, and let the parent ask for earlier breaks
only if this does not reconcile well with other conditions, for
example when reconciling breaks in the cells of a table row or
for list items.

J.Pietschmann


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: Tasks - layout

2002-08-20 Thread Keiron Liddle

On Mon, 2002-08-19 at 22:58, J.Pietschmann wrote:
 Keiron Liddle wrote:
  - Add markers to page when areas added 
 Is this really a good idea? Markers may be referenced
 long after they have been defined, tying them to the
 Page object would require keeping the pages in memory
 (see 0.20.5cvs: forward page references are *required*
 to force keeping pages in memory so that markers can
 be retrieved with document scope).

I thought the markers only apply to the current page but I haven't
really looked into it. If it does apply to pagesequence/document then it
should be on the page viewport like the id references, so that the page
can be removed leaving relevent information for use later.
There may be other places to keep the markers but the area tree might be
easier to keep track of.

 I thought about adding a running number for the page
 sequence and for the page within it's page sequence
 as well as the necessary information to make retrieving
 markers within a page work properly to the marker itself
 and store them in an Array list, with the current page
 perhaps storing the array index of the first marker of
 this page to speed up some retrieval modes.

Page numbers would be good.

I think that you only need at most four markers of a particular class
per page, so if it is a dictionary type case it doesn't need all the
markers in the middle of the page with the same class.

 J.Pietschmann



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: Tasks - layout

2002-08-20 Thread Keiron Liddle

On Mon, 2002-08-19 at 23:13, J.Pietschmann wrote:
 Keiron Liddle wrote:
  - Implement table layout 
  The table layout will use the same technique as the block layout. It
  will locate suitable breaks between rows or inside rows until table
  finished or end of bpd reached. 
 
 Actually, what *are* valid breaks within a table apart from breaks
 between two rows with no cell spanning both?
 
 Some interesting situations:
 
   +-++
   |block|block 1 |
   | |block 2 |
   +-++
 Break possibility after block 1 if
 BPD(block)BPD(block 1), i.e.
   +-++
   |block|block 1 |
   +-++
 ---
   +-++
   | |block 2 |
   +-++

For this case I would say it is a valid break. Because table row can
have keep together which only makes sense if the row can be split when
there is no keep.


   +-++
   |block block block|block 1 |
   |block block block++
   |block block  |block 2 |
   +-++
 Break possibility after row one, despite that
 the cell with block 1 would have to get some
 space after the block, i.e.
   +-++
   |block block block|block 1 |
   |block block block||
   |block block  ++
 ---
   | ++
   | |block 2 |
   +-++

It should be possible to get a break inside a cell but I don't know how
the break should be found across the row.

What happens if there is a page-break inside a cell. Do other cells go
to the end of the page or to their limit? or should the break be at the
same position across the row.


Keiron.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: Tasks - layout

2002-08-20 Thread Karen Lease

Arved,
That would be good. I haven't looked at it for a month or so, but I had 
(as usual) some questions about various statements in the XSL-FO spec 
concerning the interpretation of the various properties. Perhaps we 
could go over those issues at some point.

Karen

Arved Sandstrom wrote:

-Original Message-
From: Karen Lease [mailto:[EMAIL PROTECTED]]
Sent: August 19, 2002 6:58 PM
To: [EMAIL PROTECTED]
Subject: Re: Tasks - layout


 [ SNIP ]
 
With regard to the line-height calculations, is anybody in the group
interested in getting into the gory details of the baseline stuff for
different scripts? I spent some time poring over the spec and trying to
get a handle on this, but maybe it's too much detail for now. On the
other hand, I'd really like to make sure that this version of FOP
handles that stuff correctly as well as being able to do the various
kinds of line-stacking strategies defined by the XSL-FO spec.

 
 I am definitely interested. I have put some thought into these things
 already. Granted, when I implement it'll be a different codebase but I am
 happy to work out the details on this list.
 
 Arved
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, email: [EMAIL PROTECTED]
 
 
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: Tasks - layout

2002-08-19 Thread Keiron Liddle

On Sun, 2002-08-18 at 02:07, J.Pietschmann wrote:
 Keiron Liddle wrote:
  I don't think we should expect or even want people to understand
  everything.
 
 I think it's preferable that people hacking around in the
 code understand *something*.

Of course, but how can we make it understandable.

 I took a stab at the static content layout and even get
Great!

 some text but AcrobatReader complains about Font not
 set if there is static content. Also, the static content
 is always rendered into the upper left cornder, regardless
 which region it should be in. Meanwhile I'm completely
 out of ideas where to look, especially for the font issue.

Since each region is in its own graphics state the font needs to be set
at a higher state of for the text in each region. The problem was that
the last font state was kept from the last region.
The regions seem to be put in the right place for me, maybe the viewer
got an error so stopped doing things properly.

 Actually, how is unlimited expressed in MinOptMax terms?
 Stuffing in a large number doesn't strike me as very clean.
 I settled for the page BPD, under the assuption that the
 page viewport would not exceed this.

I'm not sure.
I could imagine that it might adjust to the size of the region. So if
larger it uses min value etc.

 J.Pietschmann



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: Tasks - layout

2002-08-19 Thread J.Pietschmann

Keiron Liddle wrote:
 - Add markers to page when areas added 
Is this really a good idea? Markers may be referenced
long after they have been defined, tying them to the
Page object would require keeping the pages in memory
(see 0.20.5cvs: forward page references are *required*
to force keeping pages in memory so that markers can
be retrieved with document scope).
I thought about adding a running number for the page
sequence and for the page within it's page sequence
as well as the necessary information to make retrieving
markers within a page work properly to the marker itself
and store them in an Array list, with the current page
perhaps storing the array index of the first marker of
this page to speed up some retrieval modes.

J.Pietschmann


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: Tasks - layout

2002-08-19 Thread J.Pietschmann

Keiron Liddle wrote:
 - Implement table layout 
 The table layout will use the same technique as the block layout. It
 will locate suitable breaks between rows or inside rows until table
 finished or end of bpd reached. 

Actually, what *are* valid breaks within a table apart from breaks
between two rows with no cell spanning both?

Some interesting situations:

  +-++
  |block|block 1 |
  | |block 2 |
  +-++
Break possibility after block 1 if
BPD(block)BPD(block 1), i.e.
  +-++
  |block|block 1 |
  +-++
---
  +-++
  | |block 2 |
  +-++


  +-++
  |block block block|block 1 |
  |block block block++
  |block block  |block 2 |
  +-++
Break possibility after row one, despite that
the cell with block 1 would have to get some
space after the block, i.e.
  +-++
  |block block block|block 1 |
  |block block block||
  |block block  ++
---
  | ++
  | |block 2 |
  +-++

J.Pietschmann


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: Tasks - layout

2002-08-19 Thread Karen Lease

Hi Keiron etc,

I'm really happy to see all this movement going on and folks from the 
maintenance branch getting into the redesign to help you out. I'm 
hoping to be able to start contributing again too, perhaps not right 
away, but hopefully in September. There may even be some possibility of 
getting to work on FOP as part of my real work, though it might be 
hard to work on the new layout in that context. I'll keep the group posted.

I'll start by looking at the latest and then maybe cogitating on list or 
table layout, depending on the timing and what others are interested in 
doing. It looks like status.xml is the sign-up sheet for the tasks; is 
that right?

With regard to the line-height calculations, is anybody in the group 
interested in getting into the gory details of the baseline stuff for 
different scripts? I spent some time poring over the spec and trying to 
get a handle on this, but maybe it's too much detail for now. On the 
other hand, I'd really like to make sure that this version of FOP 
handles that stuff correctly as well as being able to do the various 
kinds of line-stacking strategies defined by the XSL-FO spec.

Regards,
Karen

Keiron Liddle wrote:

 Now that we have some pagination there are lots of areas that people can
 work on. 
 If you want to implement any of these and have any questions then just
 ask. 
 
 Once we can get a few of these done then we could do a developers
 release. 
 
 
 - Add static areas to page 
 The static areas will need to be handled in a similar way to the flow
 except the bpd is unlimited and it will need to reset and repeat for
 each page. 
 
 
 - Add id areas to page when area added 
 When the layout managers add an area to the page it can also add the id
 information. 
 
 
 - Resolve id references on other pages, extensions 
 When an id is added to a page this will allow id references to be
 resolved. 
 
 
 - Add markers to page when areas added 
 When an area is added that is created by an FO that contains markers
 then the markers can also be added. There are four types of positions
 for markers. 
 
 
 - Retrieve markers from page 
 When doing the static areas the markers wil need to be available for
 retrieving. The marker can then be layed out as normal. 
 
 
 - calculate line height 
 The line height needs to be calculated while finding breaks. This needs
 to include all the alignment and height details of the inline areas. 
 
 
 - Various inline objects
 Page number, page number citation etc. need to be implemented.
 
 
 - Implement page caching 
 If a page need to be stored for the store pages or waiting to resolve
 forward references then we need a cache mechanism to save the page
 somewhere. 
 
 
 - Implement table layout 
 The table layout will use the same technique as the block layout. It
 will locate suitable breaks between rows or inside rows until table
 finished or end of bpd reached. 
 
 
 - Implement list layout 
 The list layout like the table layout will be looking for suitable
 breaks from the child objects. The it will add the appropriate areas to
 the area tree. 
 
 
 - Get bookmark extension working 
 Make sure the extension id references are resolved. Once the data is
 fully resolved then implement a way for the pdf renderer to add the
 bookmarks. See branch for code how to add bookmarks. 
 
 
 These are just some of the things, I will add them to the todo list.
 If there is a decent response then there are more that can be added.
 
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, email: [EMAIL PROTECTED]
 
 
 




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




RE: Tasks - layout

2002-08-19 Thread Arved Sandstrom

 -Original Message-
 From: Karen Lease [mailto:[EMAIL PROTECTED]]
 Sent: August 19, 2002 6:58 PM
 To: [EMAIL PROTECTED]
 Subject: Re: Tasks - layout

[ SNIP ]
 With regard to the line-height calculations, is anybody in the group
 interested in getting into the gory details of the baseline stuff for
 different scripts? I spent some time poring over the spec and trying to
 get a handle on this, but maybe it's too much detail for now. On the
 other hand, I'd really like to make sure that this version of FOP
 handles that stuff correctly as well as being able to do the various
 kinds of line-stacking strategies defined by the XSL-FO spec.

I am definitely interested. I have put some thought into these things
already. Granted, when I implement it'll be a different codebase but I am
happy to work out the details on this list.

Arved


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: Tasks - layout

2002-08-14 Thread Kevin O'Neill

On Wed, 2002-08-14 at 16:16, Keiron Liddle wrote:

 - Encryption and signing

Started looking at it (though I'm not using it at the moment and I'm a
little driven by the things I need :)).

 - Reusing pdf objects that links create

What do you mean ... sorry for being dim.

 - form XObject

Already started, I need it for some imposition code I'm working on
(unless someone can think of a better way to do impositioning of pages).
 
 Those are the main ones I can think of.

 
-- 
If you don't test then your code is only a collection of bugs which 
apparently behave like a working program. 

Website: http://radio.weblogs.com/0111457/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: Tasks - layout

2002-08-14 Thread J.Pietschmann

Keiron Liddle wrote:
 - Add static areas to page 
 The static areas will need to be handled in a similar way to the flow
 except the bpd is unlimited and it will need to reset and repeat for
 each page. 

I looked at it. Is static content supposed to be handled
by a FlowLayoutManager too? It seems a bit too specialized
to a fo:flow to me.

I think I understand now why the design of HEAD is as
it is now. I still think there are better possibilities,
perhaps deriving classes representing FOs from layout
manager classes, thereby avoiding communication between
the objects representing FOs and the associated layout
managers.

Does anybody dare to apply an OO metric to HEAD? Deeply
nested inheritance trees, lots of communications from
everywhere to everywhere... I'd bet the complexity is
just a notch below for supergeniuses only, which would
nicely fit the unusual long time it took me to grasp
why *anything* is laid out at all.

And:
  except the bpd is unlimited
You mean limited, do you?

J.Pietschmann


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: Tasks - layout

2002-08-13 Thread Keiron Liddle

On Mon, 2002-08-12 at 13:44, Kevin O'Neill wrote:
  These are just some of the things, I will add them to the todo list.
  If there is a decent response then there are more that can be added.
 
 Any PDF tasks?

- Encryption and signing
- Reusing pdf objects that links create
- form XObject

Those are the main ones I can think of.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: Tasks - layout

2002-08-12 Thread Kevin O'Neill

 These are just some of the things, I will add them to the todo list.
 If there is a decent response then there are more that can be added.

Any PDF tasks?

-- 
If you don't test then your code is only a collection of bugs which 
apparently behave like a working program. 

Website: http://radio.weblogs.com/0111457/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: Tasks - layout

2002-08-12 Thread J.Pietschmann

Kevin O'Neill wrote:
 Any PDF tasks?
 
Encryption related stuff seems to be often asked for.

J.Pietschmann



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]