Sounds impressive.
On Tue, Feb 03, 2009 at 07:35:03AM -0800, The Web Maestro wrote:
> Sounds exciting! Cool!
>
> On Tue, Feb 3, 2009 at 2:31 AM, Jeremias Maerki
> wrote:
> > Oh, yes, I almost forgot: I'm removing the "dy" parameter for now since
> > it's not supported anyway until we support di
On 03.02.2009 17:25:34 Georg Datterl wrote:
> Hi Jeremias,
>
> > "empty cell areas": When a table-cell is broken over two pages,
> > it generates two so-called reference areas. If the table-row that
> > it belongs to is broken over two pages but the full content of a
> > table-cell fit on the f
Hi Jeremias,
> "empty cell areas": When a table-cell is broken over two pages,
> it generates two so-called reference areas. If the table-row that
> it belongs to is broken over two pages but the full content of a
> table-cell fit on the first page, FOP still has to create a (empty)
> reference
On 03.02.2009 16:38:05 Georg Datterl wrote:
> Hi Jeremias,
>
> > Tough stuff for XSL-FO, catalogs.
> > I see multiple problems:
>
> Seeing the problems ain't my problem either. Seeing the solutions is tricky,
> :-)
>
> > Getting Block D at the bottom of the article. display-align="after" on th
On 03.02.2009 16:43:12 Chris Bowditch wrote:
> Jeremias Maerki wrote:
>
> Hi Jeremias,
>
>
>
> > Embedding the fonts is easy enough: you can just copy the files as new
> > objects into the file-level resource group. IBM's AFP Workbench will
> > still ignore the embedded fonts and replace them f
Jeremias Maerki wrote:
Hi Jeremias,
Embedding the fonts is easy enough: you can just copy the files as new
objects into the file-level resource group. IBM's AFP Workbench will
still ignore the embedded fonts and replace them for system fonts but
that's pretty irrelevant. Pixel-oriented AFP vi
Hi Jeremias,
> Tough stuff for XSL-FO, catalogs.
> I see multiple problems:
Seeing the problems ain't my problem either. Seeing the solutions is tricky, :-)
> Getting Block D at the bottom of the article. display-align="after" on the
> table-cell can help to a certain degree. Better: Setting bl
Sounds exciting! Cool!
On Tue, Feb 3, 2009 at 2:31 AM, Jeremias Maerki wrote:
> Oh, yes, I almost forgot: I'm removing the "dy" parameter for now since
> it's not supported anyway until we support different writing-modes.
> Doesn't make sense to keep that around until then.
>
> On 03.02.2009 11:1
Tough stuff for XSL-FO, catalogs.
I see multiple problems:
Getting Block D at the bottom of the article. display-align="after" on
the table-cell can help to a certain degree. Better: Setting
block-progression-dimension.maximum="1.2em" on that cell should restrict
that last row to one line, thus a
Right now, the AFP output just loads the configured bitmap and outline
fonts for metrics but it requires that the same fonts are correctly set
up on the target AFP viewer or printer. Even just registering the fonts
for FOP is tricky enough. Doing that for every target environment is
sometimes even
Oh, yes, I almost forgot: I'm removing the "dy" parameter for now since
it's not supported anyway until we support different writing-modes.
Doesn't make sense to keep that around until then.
On 03.02.2009 11:10:03 Jeremias Maerki wrote:
> I'm getting near to finishing my work on the new intermedia
Do you have a real-world example of what you're trying to build? I mean,
your earlier picture suggests that most of the EEE content belongs to
the CCC section. What is DDD? A sum at the end? I don't get how this
fits together on a logical level. Maybe you could generate the DDD in a
similar way as
I'm getting near to finishing my work on the new intermediate format.
Logically, performance tests have to show whether the goals have been
achieved. Generally, they have:
- Rendering directly from the new intermediate is a lot faster than from
the old area tree XML format.
- The new intermediate f
Hi Jeremias,
I had similar thoughts, but:
At the moment, the table would (contrary to my previous example) look like:
AAA EEE
BBB EEE
CCC EEE
DDD EEE
---break---
TH1 TH2
EEE
EEE
EEE
Cell D is on the first page, even with vertical alignment it is at best printed
on the bottom of th
Smells table-marker-ish to me. A block-container in the table-header
(retrieved through retrieve-table-marker) could display the second "CCC"
in the right position.
The only problem: someone has to implement table markers first. But I
think this would be better than to introduce yet another extens
Hello everybody,
for my project I need one final feature: Table cell duplication. Imagine a
Table like this:
TH1 TH2
AAA EEE
BBB EEE
CCC EEE
EEE
EEE
EEE
DDD EEE
Two columns, four rows, Block E spans all four rows, A aligns with the top of
the table, B and C follow, D aligns with th
16 matches
Mail list logo
