Foray's font subsystem for Fop

2005-06-12 Thread Vincent Hennebert
Hi Fop Team and Victor, I'm considering to adapt Foray's font subsystem to Fop. I have already experimented a bit and the thing seems to be rather feasible. So far I have encountered two problems: - logging mechanism: Foray uses the avalon framework while Fop uses commons logging. The 2

Re: Foray's font subsystem for Fop

2005-06-14 Thread Vincent Hennebert
Hello Jeremias, I must convey that your answer was a relief for me ;-) I was starting to wonder what I could have done wrong so that things turn out that way. I keep your technical comments in mind for later, if I eventually may work on this. Don't worry about the time I've already spent on:

FOrayFont?

2005-06-24 Thread Vincent Hennebert
Hi all... Sorry to insist, but what is your final decision? A quick summary of the thread gives: - Jeremias +1 - Simon +1 - Glen +0 The FOray+aXSL stuff would be used in the form of a jar file put in the lib directory; FOray's avalon loggers would be wrapped into a JCL adapter for now. So?

Re: AW: MathML and barcode support for FOP

2005-07-27 Thread Vincent Hennebert
While we are speaking of that, If I may give my opinion: I agree with Norman that using images to render maths isn't a good solution in the long-term. The fact that it is SVG improves the situation a bit because fonts will be rendered fine, but there are other problems to address: for example

offline

2005-07-30 Thread Vincent Hennebert
Hi all, I'll be offline during 3 weeks: summer holidays, far from computers ;-) My work on the font subsystem is getting along, a bit slowly those last days but I hope to have more time after holidays. Currently I'm on the pdf part: it's a bit difficult because font and pdf things are very

Re: Relative font weights and font selection

2005-08-12 Thread Vincent Hennebert
Victor Mote a écrit : Manuel Mall wrote: Regarding the bolder, lighter issue and the general font selection I looked at the pre-patch for FOrayFont adaptation to Fop (http://issues.apache.org/bugzilla/show_bug.cgi?id=35948) and concluded that meddling with the font selection system will

Re: svn commit: r240012 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/render: pdf/PDFRenderer.java ps/PSRenderer.java

2005-08-25 Thread Vincent Hennebert
Jeremias, Just in case you intended to do any improvement there: the FOrayFont integration may bring some facilities in this area. At least the handling will be different, so I don't think it's worth working on this before the integration is done. So please leave it as is for now. Thanks!

Re: Relative font weights and font selection

2005-08-26 Thread Vincent Hennebert
Victor Mote a écrit : I am ignoring font-stretch for now. I am unclear whether it works similarly to font-weight, or whether it is totally resolvable in the FO Tree. Interestingly, CSS 2.1 (the only version of CSS 2 still available at W3C) removes font-stretch entirely!!??!! As I understand

Re: Relative font weights and font selection

2005-08-27 Thread Vincent Hennebert
Victor Mote a écrit : As I understand the spec, this works differently from font-weight and can be resolved in the FO Tree: just select the next expanded value for wider or next condensed for narrower. The font selection would be performed only after, when it is time to decide e.g. which font

Re: [Xmlgraphics-fop Wiki] Update of ReleasePlanFirstPR by ChrisBowditch

2005-08-31 Thread Vincent Hennebert
Chris, I'm afraid I don't agree with you here. You seem to mix up space conditionality and space precedence. See § 4.3 of the spec, and especially § 4.3.1, Space-resolution rules [1] Conditionality only stands for spaces that begin a reference area; as per the first rule, all of the

Re: [Xmlgraphics-fop Wiki] Update of ReleasePlanFirstPR by ChrisBowditch

2005-08-31 Thread Vincent Hennebert
Chris Bowditch a écrit : The second fo:block does not begin a reference area, so space conditionality isn't taken into consideration. For both spaces, precedence is not specified so the default value of 0 is used (§ 7.10.5 7.10.6). The third rule of § 4.3.1 states that between the two

Re: [Xmlgraphics-fop Wiki] Update of ReleasePlanFirstPR by ChrisBowditch

2005-08-31 Thread Vincent Hennebert
Manuel Mall a écrit : I would have thought its more of a nice to have but not a requirement for this release. Exactly. If FOrayFont is ready for this release, all the better. It's difficult to say if it will be. The pdf library is now converted, PDFRenderer almost. I think the PSRenderer

Re: e-g with padding and borders

2005-09-01 Thread Vincent Hennebert
I'm not sure here. The fo:external-graphic uses the large-allocation-rectangle (§ 6.6.5), that comprises padding and border. This makes me say that in Manuel's example the fo:block's bpd should be calculated with the second formula. The fo:block's content forms a line whose

Re: [Xmlgraphics-fop Wiki] Update of ExtensionPoints by JeremiasMaerki

2005-09-02 Thread Vincent Hennebert
Luca, I'm speaking here as a (future) Fop user. Just to let you know that I'm definitely wanting to support you in this area. I think your extensions would make Fop an extremely powerful typesetting system, that would eventually beat TeX in the quality of page makup. It's all the more

Re: e-g with padding and borders

2005-09-02 Thread Vincent Hennebert
Jeremias Maerki a écrit : The real problem IMO is probably block-level content in fo:inlines again. How are these borders to be painted? A border around each inlineblockparent (one for each block inside the inline)? I'm not sure judging from the specification. Here the spec starts being really

Re: e-g with padding and borders

2005-09-02 Thread Vincent Hennebert
What disturbs me is that when one specifies a border around a chunk of text and there is line-breaking, this border should appear and the end of the first line and the beginning of second line, as below: This is a | chunk of text | -

Re: e-g with padding and borders

2005-09-02 Thread Vincent Hennebert
Hi Andreas, You're right. Indeed both situations below are handled by the standard, thanks to border conditionality and is-first/is-last traits. Thanks for the pointer! Vincent Andreas L Delmelle a écrit : On Sep 2, 2005, at 17:44, Vincent Hennebert wrote: Hi, snip

Re: Logging for FOrayFont

2005-09-03 Thread Vincent Hennebert
Hi Victor, What I liked with the Avalon Logger is the one-to-one correspondance between it and Commons' Log; commons just has one more level which is trace. So writing a Logger adapter that delegates logs to a Log instance is trivial. Now it's different because PseudoLogger has 7 log levels

Re: Logging for FOrayFont

2005-09-04 Thread Vincent Hennebert
Victor Mote a écrit : Actually there is not a level named debug, although I might have defined that constant equal to finest in one of the earlier versions. This does not appear in CVS. I would suggest you to redefine such a constant to remove any ambiguity, as as you can see it confused me.

Re: regions and writing-mode

2005-09-04 Thread Vincent Hennebert
Hi Manuel, Sorry for the delay. I think you're right. See the note in 6.4.12 fo:simple-page-master: For example, if the writing-mode of the fo:simple-page-master is lr-tb, then [region-body, region-before, region-after, region-start, and region-end] correspond to the body of a document, the

Re: Logging for FOrayFont

2005-09-05 Thread Vincent Hennebert
I'm satisfied with your explanations. Please just add a LEVEL_DEBUG constant and I'm OK with your interface. OK, I have added the constant LEVEL_DEBUG back, and have also added a new one called LEVEL_TRACE. PLEASE NOTE: LEVEL_DEBUG is now equal to LEVEL_FINER (it previously was equal to

User config file currently discarded

2005-09-06 Thread Vincent Hennebert
Hi, By trying to debug my FOrayFont adaptation I noticed that the user config file currently isn't taken into account by the Trunk. The apps.FOUserAgent.getConfig() method is actually never called within the code, and (as a consequence I suppose) neither is the

Re: User config file currently discarded

2005-09-06 Thread Vincent Hennebert
Jeremias Maerki a écrit : Actually, everything is fine with the code. The renderer is already configured through the RendererFactory. I assume the problem is the changed format of the userconfig.xml file. I've attached a demo file. Oh well. I didn't realize that the conf/fop.xconf file in the

FOrayFont, PS/PDFTranscoders and SVG handling

2005-09-12 Thread Vincent Hennebert
I'm about to convert the SVG library to FOrayFont. But the Batik side seems to be reluctant to see the transcoders converted to FOrayFont [1]. How should I handle that? I guess I should leave existing files as is and provide new files corresponding to the FOrayFont implementation? How should I

Re: FOrayFont, PS/PDFTranscoders and SVG handling

2005-09-12 Thread Vincent Hennebert
Jeremias and Victor, thanks for the hints. I keep them under the hand for later, when it is time to migrate the stuff into XML Graphics Commons. For now I just override current implementations with FOrayFont. Anyway it will possible to recover them with svn, in case they have to coexist.

PSDocumentGraphics2D and Font dictionary

2005-09-12 Thread Vincent Hennebert
In PSDocumentGraphics2D.writeFileHeader (and also in PSRenderer.startPageSequence) the font dictionary is written into the PS file by a call to PSFontUtil.writeFontDict. At this time all of the fonts present in the fontInfo (defaults + those found in the config file) seem to be written out,

Re: PSDocumentGraphics2D and Font dictionary

2005-09-12 Thread Vincent Hennebert
, in a way, the same problem. So you see: the problem is speed versus beauty. BTW, that was the reason why I started introducing a better resource handling with PS support, so we can later add such a mode where we write the PS file in a two-pass approach. On 12.09.2005 21:40:11 Vincent Hennebert wrote

Re: PSDocumentGraphics2D and Font dictionary

2005-09-13 Thread Vincent Hennebert
Let's look at it from another side. If someone writes some kind of FO editor or a configuration tool for FOray/FOP a method that reports all available fonts will certainly be useful. :-) OK. That makes sense. To avoid wasteful parsing, it will mean that at least 3 new classes need to be

Re: PSDocumentGraphics2D and Font dictionary

2005-09-13 Thread Vincent Hennebert
Victor Mote a écrit : I am not sure what you mean getPDF/PSSubset. If I'm correct it is only possible to embed the whole font file in a pdf output, by using getPDFFontFileStream. Currently aXSL doesn't seem to provide a means to embed only a subset. Point me to the FOP code that does the

Re: PSDocumentGraphics2D and Font dictionary

2005-09-13 Thread Vincent Hennebert
Victor Mote a écrit : Jeremias Maerki wrote: output format. Maybe the Font interface should simply have a method to return a very generic interface for more detailed and font- and output-system-specific access to the font. Consumers of this interface can then cast it to a special

Re: FOray contacts

2005-09-15 Thread Vincent Hennebert
I completely agree with Manuel. Whereas I can feel your disagreement with some decisions for the project you have always remained nice and made valuable comments. I regret your decision to leave this list because you have often been helpful where you were not expected. I'll be glad to

2 weeks offline

2005-10-25 Thread Vincent Hennebert
Hi all, I'll be offline from tomorrow for 2 weeks: visiting Japan. Although I don't have had much time to work on Fop those last days I don't abandon my work. I've taken a little break in the adaptation to learn a bit of PDF. I think this is necessary to better understand what I'm doing.

Re: Preparing for the first release

2005-11-14 Thread Vincent Hennebert
Manuel Mall a écrit : As the project hasn't done a release for a long time and especially no release of the new codebase we should test probably a bit more extensively than usual that the distribution builds actually are working and don't contain any 'cheap' errors. To that effect I have

Re: svn commit: r348291 - /xmlgraphics/fop/trunk/src/documentation/content/xdocs/dev/release.xml

2005-11-23 Thread Vincent Hennebert
Author: jeremias Date: Tue Nov 22 15:34:57 2005 New Revision: 348291 URL: http://svn.apache.org/viewcvs?rev=348291view=rev Log: Collect places to announce FOP releases. Modified: xmlgraphics/fop/trunk/src/documentation/content/xdocs/dev/release.xml Modified:

Re: Non scalable fonts

2005-11-25 Thread Vincent Hennebert
Hi Manuel, Just came across a scenario (AFP Renderer) where I need to support non scalable fonts. The current FOP trunk font system is not very good at this as it does font selection purely based on (name, style, weight). Does FOray font support non scalable fonts (raster / bitmap fonts)?

Re: Text handling in svg files, transcoders

2005-11-25 Thread Vincent Hennebert
[EMAIL PROTECTED] a écrit : Hi Jeremias, Vincent, I would need some help to understand how transcoders and text handling within svg should work. o first, when I try to convert some svg that contains text into pdf with Batik (1.6), text is always rendered as strokes, even if it would be

Re: Text handling in svg files, transcoders

2005-11-26 Thread Vincent Hennebert
Hi Thomas, [EMAIL PROTECTED] a écrit : But this doesn't work when I run Fop with the same svg included in an fo file. Am I missing something? I take it this is an FO with inline SVG consisting of an SVG 'image' element referencing the SVG file? The svg file is referenced by an

Re: Text handling in svg files, transcoders

2005-11-28 Thread Vincent Hennebert
Jeremias Maerki a écrit : On 25.11.2005 16:25:43 thomas.deweese wrote: snip/ Thomas, what do you think about this topic? Well I think that currently the text bridges do a pretty good job determining if they are capable of drawing text as PDF text and drop back to curves when needed. I

Re: Text handling in svg files, transcoders

2005-11-28 Thread Vincent Hennebert
Jeremias Maerki a écrit : Hey, allow me some wishful thinking on my part. :-) Look, if FOrayFont supports fonts without the need for a PFMReader or a TTFReader then the road to font auto-discovery is just a very small step. And the former is an absolute must. Otherwise, the whole thing is a

Re: [was in Fop-user] text search in PDF

2005-11-29 Thread Vincent Hennebert
Jeremias Maerki a écrit : Well, this has been a known issue for a long time and it is still not adressed in FOP 0.90alpha1. However, someone is working with the FOray project to build a better font library for FOP. Victor Mote already fixed the problem in his FOray but I can't tell what the

Re: MathML for fop-trunk

2005-12-09 Thread Vincent Hennebert
metrics? Where we could start look at that? In FOP Trunk, the fonts package. Everything's there. However, currently Vincent Hennebert works on integrating the font subsystem from FOray which will be a little different. It may make sense not to rush into anything too quickly here. Vincent

FOrayFont patch almost ready

2005-12-12 Thread Vincent Hennebert
Team, I've just posted an updated pre-patch of my FOray adaptation work. I put it as a pre-patch because the junit tests don't run well anymore (about 75 errors with junit-layout-standard). However, the pdf output looks right on the few tests I have run. The weird thing is that the XML renderer

Re: FOrayFont patch almost ready

2005-12-13 Thread Vincent Hennebert
-patch? :-) On 12.12.2005 22:44:04 Vincent Hennebert wrote: Team, I've just posted an updated pre-patch of my FOray adaptation work. I put it as a pre-patch because the junit tests don't run well anymore (about 75 errors with junit-layout-standard). However, the pdf output looks right on the few

Re: DO NOT REPLY [Bug 37879] - PDF SVG rendering forces stroking text (config setting broken)

2005-12-13 Thread Vincent Hennebert
Don't know it this bug should be closed? Vincent [EMAIL PROTECTED] a écrit : DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37879. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE

Transcoders and font configuration

2005-12-13 Thread Vincent Hennebert
This is perhaps more just for the record. FOrayFont needs a font-config file to run properly; the most basic file will only contain the paths to the base14 metrics afm files. If no config file is specified then no font will be configured, which will obviously lead to rendering errors. I don't

Re: Review of the FOrayFont patch and FOrayFont itself

2005-12-22 Thread Vincent Hennebert
Damn :-( Looks like some more work is needed. Problem is that it does no longer depend only on me. Basically I agree with reasons 1. and 3. I don't really get the second one, perhaps because I don't have a broad view of the problem. However the distinction between system fonts and free-standing

Re: Combine FOP PDFBox efforts?

2006-03-15 Thread Vincent Hennebert
Hi Ben, hi All, I finally have some time to chime in, sorry for the delay. Thank you for your interest in the font subsystem. My goal is to adapt the FOrayFont library to Fop. The main advantage of FOrayFont over the Fop code is its ability to directly parse font files, whereas currently with

Re: Combine FOP PDFBox efforts?

2006-03-16 Thread Vincent Hennebert
Great, I will start updating PDFBox to use the FOrayFont, I believe this will go pretty smoothly because FOrayFont is already being used for PDF creation. More details on the FOray list. We have had some recent discussions about supported JRE's, from the main page of FOray[1] it says that

Re: Google Summer of Code

2006-04-19 Thread Vincent Hennebert
Jeremias Maerki a écrit : I don't see why you couldn't also apply for a slot. Having floats would be cool (but not simple). I'm not sure about your work on FOrayFont. I think the projects have to be tied to one of the organizations listed by Google. Only the client part in FOP would be part of

Re: Google Summer of Code

2006-04-23 Thread Vincent Hennebert
Hi, I'm thinking about setting up a page on the FOP-wiki where I would put up the goals for my proposal. That way I could give the link when submitting my application. Nice idea, indeed. I've taken the liberty of implementing it and created a new Wiki page for the SoC, linked from the

Re: Google Summer of Code

2006-04-24 Thread Vincent Hennebert
Hi Jeremias, Thanks for your review! Vincent, a comment on yours: For before-floats, you refer to best-fit and first-fit approaches. I'm not sure if it's really relevant here. If I'm not mistaken before-floats are pretty similar to footnotes which means you can probably take a lot from there.

Re: Google Summer of Code

2006-05-07 Thread Vincent Hennebert
Paul wrote: Same here, I've added an entry for auto table layout, right after Vincents. Patrick Vincent Hennebert wrote: Ok, I've added an entry for floats implementation. I'll be off-line from tomorrow until the 6th of may. Just hoping no particular problem will occur during my absence

Re: Google Summer of Code

2006-05-07 Thread Vincent Hennebert
Ok, this should have worked this time. Don't know what happened. Vincent Jeremias Maerki a écrit : Vincent, I'm afraid I don't see your application, either. You could simply try again or contact the GSoC support. On 07.05.2006 19:12:26 Vincent Hennebert wrote: Hi Jeremias, Normally my

Re: Google Summer of Code

2006-05-24 Thread Vincent Hennebert
table layout. Thank you very much Jeremias for taking the time to apply as a mentor and rank our projects. Patrick Jeremias Maerki wrote: Got it and rated it. All green! :-) On 07.05.2006 22:24:26 Vincent Hennebert wrote: Ok, this should have worked this time. Don't know what happened

Re: svn commit: r406917 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/fonts/truetype/TTFFile.java status.xml

2006-05-25 Thread Vincent Hennebert
snip/ Also do we know what Foray Fonts does? Prefers the OS/2.sTypeAscender over hhea.Ascender just like FOP did before my patch. FWIW: I've just noticed Victor of the issue. Just waiting for his comments. BTW, my work on fonts (which already wasn't going very fast) may further suffer from

Re: Google Summer of Code

2006-05-29 Thread Vincent Hennebert
Hi Simon, Simon Pepping a écrit : I have winters of code and summers of less code. That diminishes my ability to provide assistance. What kind of work and responsibilities would assistance include? What would be the time constraints, that is, how fast needs a review be done or a question be

[GSoC] Wiki page for progress informations

2006-05-29 Thread Vincent Hennebert
Hi all, As you may have already noticed, I've created a Wiki page [1] which will contain progress informations on the implementation of floats for the Summer of Code. I'm planning to use this page somewhat as a blog, which I'll try to update regularly. Any comments will be welcome at any time

Re: Google Summer of Code

2006-05-30 Thread Vincent Hennebert
Hi Simon, Simon Pepping a écrit : I have one small comment on your decomposition of the line breaking algorithm: * defining a somewhat arbitrary formula used to compute the demerit of each break, and which is to be minimized; I find the above second item in this list a bit misplaced.

Re: [GSoC] Wiki page for progress informations

2006-05-30 Thread Vincent Hennebert
Hi Jeremias, Jeremias Maerki a écrit : did you already investigate how footnotes are implemented? Can you say anything about how similar the problem of footnotes is to before-floats? Just so you don't have to start from scratch while there may be something to build upon. After all, the

Re: [GSoC] Wiki page for progress informations

2006-05-31 Thread Vincent Hennebert
Thanks a lot Luca! This will help me find my way in the code. I keep your comments in mind for when I better understand the whole issue. Vincent Luca Furini a écrit : Jeremias Maerki wrote: did you already investigate how footnotes are implemented? Can you say anything about how similar the

Plass' thesis: Optimal Pagination Techniques...

2006-06-01 Thread Vincent Hennebert
Hi all, A bit more than one year ago Plass' thesis was cited on this list [1]. By looking at the 24 Page Preview available on the site it seems that this works may help me to have a better understanding of the issue, and solves some of the problems I raised on the Wiki. I would like to have the

Re: Plass' thesis: Optimal Pagination Techniques...

2006-06-02 Thread Vincent Hennebert
. :-) Anyway, the thesis seems to contain a lot about before-floats. Actually, IMO, the thesis title is too generic for what's inside. I think you could get quite a bit out of it for your project. On 01.06.2006 19:41:38 Vincent Hennebert wrote: Hi all, A bit more than one year ago Plass' thesis

Re: [Xmlgraphics-fop Wiki] Update of GoogleSummerOfCode2006/FloatsImplementationProgress by VincentHennebert

2006-06-09 Thread Vincent Hennebert
Hi Jeremias, I was precisely starting to think about that. It's probably time to ask the question I had for a while regarding the patch policy: what I'm tempted to do is open just one bugzilla entry which could be entitled GSoC floats, and where I would post all the modifications I will make

Re: [Xmlgraphics-fop Wiki] Update of GoogleSummerOfCode2006/FloatsImplementationProgress by VincentHennebert

2006-06-11 Thread Vincent Hennebert
I've looked at all the pages in the section Documents with Relation to the Knuth Approach of DeveloperPages, which provide a good starting point. I don't think there are other pages elsewhere? Vincent Simon Pepping a écrit : Vincent, Are you aware that Luca has documented his implementation

Re: Bug 5335 (cut and paste) question

2006-06-13 Thread Vincent Hennebert
. Unfortunately I can allocate only very little resource to this task. HTH, Vincent Karl Roberts a écrit : Hi, This is a quesstion for Vincent Hennebert, as I believe, from responses Jeremias has given me, you are working on this with the FOray project to fix this. Do you know how close

Re: DO NOT REPLY [Bug 39777] - [PATCH] GSoC: floats implementation

2006-06-13 Thread Vincent Hennebert
Hi, --- Additional Comments From [EMAIL PROTECTED] 2006-06-12 12:45 --- (In reply to comment #0) This patch isn't really meant to be applied... Rather to be reviewed by interested parties to check if I'm not wrong. Changelog: * javadocs for the Knuth line- and page-breaking

Re: keep...=always and Knuth penalties

2006-06-19 Thread Vincent Hennebert
FYI: I'm planning to refactor the breaking algorithm in order to implement floats. I'll see what can be done in this area. Just keep in touch. Vincent Manuel Mall a écrit : On Monday 19 June 2006 16:45, Jeremias Maerki wrote: On 18.06.2006 20:57:51 Simon Pepping wrote: On Sun, Jun 18,

[GSoC] How the work should progress

2006-06-21 Thread Vincent Hennebert
Hi all, I'd like to have the opinion from the team about how I should proceed. I'm currently at a point where I think I know enough, both from theoretical and code points of vue, to start the implementation of floats. By mimicing the handling of footnotes, I think I can have a working

Re: [GSoC] How the work should progress

2006-06-23 Thread Vincent Hennebert
. If not, I'll follow Simon's advice and refactor just what is necessary to implement floats. Cheers, Vincent Simon Pepping a écrit : On Wed, Jun 21, 2006 at 04:32:29PM +0200, Vincent Hennebert wrote: Hi all, I'd like to have the opinion from the team about how I should proceed. I'm currently at a point

Re: [GSoC] How the work should progress

2006-06-26 Thread Vincent Hennebert
Hi Jeremias, snip/ Please do try to refactor the footnote and before-float stuff out into a separate class to make the whole design clearer. But don't shift your focus too much. Some factoring: +1, total refactoring -0.5, keep focus on your task: +1. ;-) Ok. So definitely I'll just refactor

PercentBaseContext uselessly inherited

2006-06-29 Thread Vincent Hennebert
Hi all, I've noticed that many *LayoutManager classes explicitly implement the datatype.PercentBaseContext interface while it is already extended by the LayoutManager interface. Same for the BlockLevel- and InlineLevelLayoutManager interfaces. All those classes or interfaces, which implement or

Re: PercentBaseContext uselessly inherited

2006-06-29 Thread Vincent Hennebert
Hi all, I've noticed that many *LayoutManager classes explicitly implement the datatype.PercentBaseContext interface while it is already extended by the LayoutManager interface. Same for the BlockLevel- and InlineLevelLayoutManager interfaces. All those classes or interfaces, which implement or

Re: Error message: Should be first

2006-07-10 Thread Vincent Hennebert
One of my clients reported to me that he gets a Should be first error message on the log. This happens in (Page)BreakingAlgorithm.removeNode(). I get the impression that the code there is not finished rather than that is a real error condition. I'll try to extend removeNode() so it really removes

Necessary conditions to defer footnotes

2006-07-11 Thread Vincent Hennebert
Hi All, there is something I don't get with the handling of footnotes. When there is not enough room on the current page to place all the footnotes, the algorithm tries to find a place where to split them. But there is a condition: it must be possible to defer old footnotes

Re: Invitation to Cocoon's GetTogether

2006-07-13 Thread Vincent Hennebert
Jeremias Maerki a écrit : Andreas, what about you? Could you make it to the Cocoon GetTogether? One or two days of Hackathon (discussions, hacking, fun). Anyone else? Jörg, Chris, Finn, Peter, Vincent maybe? I don't know yet what will be my situation at that time, but I will do my best to

[GSoC] BreakingAlgorithm: simplify handling of activeLines

2006-07-17 Thread Vincent Hennebert
Hi All, Good news: before-floats are working. There probably are bugs and place for improvement but I think it is time to submit a first patch, so that you may see what I've done. I'm currently cleaning up and documenting my code, and I think the handling of the activeLines array may be

Re: [GSoC] BreakingAlgorithm: simplify handling of activeLines

2006-07-18 Thread Vincent Hennebert
Hi All, Good news: before-floats are working. There probably are bugs and place for improvement but I think it is time to submit a first patch, so that you may see what I've done. I'm currently cleaning up and documenting my code, and I think the handling of the activeLines array may be

Two days offline

2006-07-22 Thread Vincent Hennebert
I personally would gladly work, but my brain no longer wants to. Guess I need a break. Vincent

Re: DO NOT REPLY [Bug 39777] - [PATCH] GSoC: floats implementation

2006-07-25 Thread Vincent Hennebert
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=39777. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.

Re: DO NOT REPLY [Bug 39777] - [PATCH] GSoC: floats implementation

2006-07-31 Thread Vincent Hennebert
I managed to reenable one of the disabled test cases because you were fooled by the default values for widows and orphans. Having only 3 lines in a block does not allow any break possibilities with default widows and orphans. 4 lines creates one break possibility in the middle. Indeed, yes.

space-start and space-end for block-areas

2006-07-31 Thread Vincent Hennebert
Hi all, I think there is a problem in the spec regarding the space-start and space-end traits for block-areas. The like-named properties only apply to inline-level formatting objects, so I guess that for block-areas those traits are indirectly-derived from other properties (start-indent and

Re: space-start and space-end for block-areas

2006-08-01 Thread Vincent Hennebert
Really want to dig that one out again? :-) He he ;-) I guess yes. I was starting to look at all the intrusion-adjustment and -displace stuff when I stumbled upon this issue. I need to have an absolutely clear understanding of that if I want to implement side-floats correctly. Before I go

Re: space-start and space-end for block-areas

2006-08-01 Thread Vincent Hennebert
snip/ Ah yes, so this formula comes from the statement in 7.10.7 (BTW, in case of mixed writing modes / reference-orientations this statement is wrong; I don't think so. FOs like block-container create a viewport/reference pair. The viewport-area does the rotation, the reference-area is

Re: space-start and space-end for block-areas

2006-08-02 Thread Vincent Hennebert
snip/ PS: There seems to be a problem, then, with the third paragraph of the attached fo file. IIUC it should be placed 1 cm right from the black border. And if I remove the start-indent=0 attribute from the fo:block it should be placed 2 cm right. WDYT? Yes, that's what's

Re: Implementing OpenType font support, how hard?

2006-08-02 Thread Vincent Hennebert
should have some time again to work on this from mid-september on (mmmh, is it too late for you?). snip/ 2d) Re-enable kerning, as OpenType fonts are usually of high quality and deserve to be used with automatic kerning. Ok, that should be obsolete. One point about 2) is that Vincent Hennebert

start-indent for line-areas

2006-08-03 Thread Vincent Hennebert
Hi All, Hem, once again :-\ In section 4.5 of the spec it is written that, for a line-area, the start-edge of its allocation-rectangle is offset from the start-edge of the content-rectangle of the nearest ancestor reference-area by the sum of its start-indent and start-intrusion-adjustment.

Re: start-indent for line-areas

2006-08-04 Thread Vincent Hennebert
A line-area is a special sort of block-area (4.5, 1st sentence), it does not have any border and padding. Furthermore, 4.4 defines the behaviour of block-areas and makes special comments that many of those feature don't apply to block-areas which are line-areas (for example for start/end-indent).

Re: [Xmlgraphics-fop Wiki] Update of GoogleSummerOfCode2006/FloatsImplementationProgress/ImplementingSideFloats by VincentHennebert

2006-08-11 Thread Vincent Hennebert
2006/8/11, Apache Wiki: Dear Wiki user, You have subscribed to a wiki page or wiki category on Xmlgraphics-fop Wiki for change notification. The following page has been changed by VincentHennebert:

Re: [Xmlgraphics-fop Wiki] Update of GoogleSummerOfCode2006/FloatsImplementationProgress/ImplementingSideFloats by VincentHennebert

2006-08-11 Thread Vincent Hennebert
2006/8/11, Jeremias Maerki: snip/ In some situations, a best-fit approach could even produce better results, as we would have the possibility to consider the differing of a side-float. But it is well-known that best-fit may be much worse than total-fit regarding before-floats and footnote

Re: [Xmlgraphics-fop Wiki] Update of GoogleSummerOfCode2006/FloatsImplementationProgress/ImplementingSideFloats by VincentHennebert

2006-08-15 Thread Vincent Hennebert
Hi Simon, Vincent, This page represents a good piece of work. First some nit picking regarding language: 'A, if X; B, else': change else - otherwise (2x) 'We may choose to either differ a side-float, or ...': change differ - defer Thanks. Changed. Then a comment on the rules: Rule 1.

Re: [Xmlgraphics-fop Wiki] Update of GoogleSummerOfCode2006/FloatsImplementationProgress/ImplementingSideFloats by VincentHennebert

2006-08-15 Thread Vincent Hennebert
2006/8/15, Simon Pepping: Hi, One more thing. All your beautiful pictures are on your own web site. Would you mind if we copy the pictures to the home page of one of the committers on people.apache.org, and change the links on the Wiki page? That is a more permanent solution. I fully agree.

Re: Some comments on improving the algorithm for before-floats

2006-08-16 Thread Vincent Hennebert
Hi Simon, Ok, I've taken out my LaTeX book again to be sure I understand you. Vincent, Your proposal to improve the algorithm for the placement of footnotes and before-floats sounds fine. A few comments. 'Ideally there would be a configuration setting telling which ratio of the page should

Re: [Xmlgraphics-fop Wiki] Update of GoogleSummerOfCode2006/FloatsImplementationProgress/ImplementingSideFloats by VincentHennebert

2006-08-18 Thread Vincent Hennebert
Hi Simon, 2006/8/17, Simon Pepping: Rule 1. Why does the rule not require not both x = 0 and x + ipd = ipd(ref-area), for both start and end floats, unless the float is wider than the ipd(ref-area)? In other words, why is rule 7 not required for any start and end floats? Hey, you're

[GSoC] Quick news

2006-08-21 Thread Vincent Hennebert
Hi all, The GSoC is over :-( I wanted to submit a patch containing a full implementation of before-floats before the end of the GSoC, but it turns out that this was more difficult than expected. Currently there are plenty of bugs, no line of javadoc, no comment, much cleanup to do, etc. But

Re: [GSoC] Quick news

2006-08-22 Thread Vincent Hennebert
Ok, I'll need a couple of additional days to finish this work. Between a research paper and the actual code there is quite a gap... I had some hard time trying to find a proper design, dealing with special cases while factorizing the common code. In particular, deciding how to handle

Re: [GT2006] Registration is open! Cocoon GetTogether 2006 (Oct 2-4,Amsterdam)

2006-08-27 Thread Vincent Hennebert
He he, you can count me in guys. I'm looking forward to meet you in real life. I should be there for both days. Are you planning to participate in the evening events? Or do we organize our own? Vincent 2006/8/22, Jeremias Maerki [EMAIL PROTECTED]: I for both days. Arriving late Monday

Re: FOP Poster

2006-08-28 Thread Vincent Hennebert
2006/8/28, Jeremias Maerki: Gang, I've finally finished (more or less anyway) the poster I plan to put up at OpenExpo on 2006-09-20. I'd appreciate if someone could take a quick peek and tell me if it's looking too ugly or if there are any spelling mistakes. The logos may seem a bit dark on

Re: [GSoC] Quick news

2006-08-29 Thread Vincent Hennebert
Thanks for your support, guys. I've made some progress since last week, but there are still some bugs well hidden here and there, and unexpected behaviors (but also some improvements, phew). For now I'll take a little break and spend some time with my family. I should get back to work in one

Re: Implementation of hyphenation-keep property

2006-09-01 Thread Vincent Hennebert
Hi all, My 2 cents, as I don't have a detailed understanding yet of all the issues raised here. Globally we agree that the line- and page-breaking algorithm should be modified to exchange some information. Now I have the feeling that backtracking is actually not necessary. I've put some words

Re: svn commit: r442282 - in /xmlgraphics/fop/trunk: ./ src/documentation/content/xdocs/trunk/ src/java/org/apache/fop/fo/ src/java/org/apache/fop/fo/extensions/ src/java/org/apache/fop/fo/extensions/

2006-09-12 Thread Vincent Hennebert
2006/9/11, Jeremias Maerki: As mentioned last month, I just changed the property names a little bit. If anyone finds these inappropriate, please yell. This is not a big deal, but the names bother me a bit. Reading widow-content-limit makes me believe that that corresponds to the maximum

  1   2   3   4   5   6   7   8   9   >