ue to get my real work done and still cooperate with the FOP
development team.
I hope that no one will think that I am recruiting here. I simply thought it
would be rude for you to hear about this some other way. I wish you all
success.
Victor Mote
r home on Apache for the independent modules, but I
frankly don't have time to jump through all of their hoops. The great
benefit to using sourceforge was the easy access. I can still get and
receive the benefits of an open-source approach and let you guys stay on
track with your work.
Victor Mote
eak the implementation into the two projects that it is in
today? All we are really talking about here is the principle of
encapsulation writ large.
Victor Mote
ust last week). The fact that you are successfully modularizing trees into
branches and leaves is no argument against FOP modularizing the forest into
trees.
Victor Mote
If FOray has any success at all, you all will have
another opportunity to address the issue.
Victor Mote
ost of the time.
However, I obviously hope that you will check in from time to time to see
whether we have anything useful for you. Please let me know if I can help in
any way.
I will probably unsubscribe fop-dev in the next few days, so if I don't
respond here, contact me off-line or through FOray.
Victor Mote
pache License 2.0. ATM, all files still have the
1.1 boilerplate.
Victor Mote
l take you
here:
http://sourceforge.net/projects/foray/
Victor Mote
ogic into the pdf output library, instead of fonts), because not
everything wanting Font support needs the ability to embed a font in PDF,
while almost certainly anything creating PDF will want to embed fonts.
Victor Mote
; through
the lens of the RenderContext before it can be used properly. That is
probably why the Font stuff ended up in the Render classes. And that is
(part of) why I think, as FOP grows up here, it is important to distinguish
between the Renderer and the RenderContext.
If you'll give me a few weeks, I hope to be able to show you what I seem
unable to sell with words.
Victor Mote
ot work. I run all of my stuff in
a headless environment to PDF, with no problems. If you can provide some
details here, I am very interested to identify any RenderContext
differences.
Victor Mote
places that it can be.
Are you suggesting that FOP / FOray needs to actually query the hardware
device and extract metrics information directly from it? Or is the plan I
have outlined above sufficient?
Victor Mote
hen someone would have to sit
down and either query the device or infer the metrics from output, or some
other method to get it into the standard form expected. It might be
worthwhile to add something in the font configuration that would identify
the point size, so that at least a warning could be generated if someone
tried to use, say, an 11-pt file at 9 points.
Victor Mote
dobe's fonts, it seems like a good
thing for it to only have to respond to querys about the 3 that are actually
used in a document, rather than build all 2300 and tell the system about
each of them.
Thanks for the good feedback.
Victor Mote
p;m=107074009107318&w=2
and it has never been answered by Peter or Glen or anyone else.
It is no longer a concern of mine that FOP has returned to a monolithic
design, but I think it is a bit unfair to the new developers to imply that
the XSL-FO standard mandates such a design, at least with the reasoning that
has been offered so far.
Victor Mote
Peter:
Best wishes to you both.
Victor Mote
> -Original Message-
> From: Peter B. West [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 17, 2004 7:07 AM
> To: fop-dev
> Subject: Offline
>
> Fopfellows,
>
> I will be offline for the next week. I'm
l-fop/src/documentation/resources/images
/logo2.ai
Here is the concurrent mailing list discussion:
http://marc.theaimsgroup.com/?l=fop-dev&m=107091332015607&w=2
Victor Mote
k at it and
comment on it any time you wish, but I'll try to have something more
official and definitive after I get back.
Victor Mote
ll,
allowing a layout engine to use something other than page-sequence as a
trigger. I thought at the time that this might be helpful to those wanting a
more "eager" layout strategy.
Victor Mote
d; if not, that is OK too.
Please let me know if there is anything I can do to help.
Victor Mote
code. I *think* that is pretty easy for Fonts and Graphics,
but, as you say, probably not as easy for PDF, and probably PostScript too.
Victor Mote
h PDF and PS, we run the risk of
losing some large chunks of utility if we don't have either 1) someone
familiar with the changes guide the porting, or 2) someone go through some
detailed diff work to try to ferret out the changes. I just want to make
sure that my insistence in starting with the maintenance branch code instead
of HEAD isn't perceived as underestimating the difficulty in that approach.
It is ugly -- I just think it is less ugly than the alternatives.
Victor Mote
r the inconvenience. I really should have done this from the
start.
Victor Mote
ions to only that
one must result in the maximum resources being bent toward that goal, right?
Is anyone familiar with the economic concept of Unintended Consequences?
I don't mean for this to be a rant, nor do I want it to slow anyone down. I
just want to make very sure that no one thinks I agree with this stuff,
especially when no convincing case has ever been put forth that it is a Good
Thing.
Victor Mote
ootnotes or multi-column layout working better? Are you reminding us of
your neutrality on modularity? Or are you saying that this kind of question
is irrelevant? Please let me remind you that I was responding to a direct
question.
Victor Mote
ants to pick
this up, I'll start a 0.2 branch.
Victor Mote
it
becomes more practical to "diff" them for debugging.
Victor Mote
Victor Mote wrote:
> Does anyone else wish to take up this project? It would seem
...
> Whether through FOP or FOray, my goal is to get a general
> release completed before the end of September, so please let
> me know whether FOP wants to be part of it.
I conclude from the sile
e hard to imagine what might induce me to give that
up. Nevertheless, I'll watch with you to see if that possibility presents
itself.
Victor Mote
Anton Tagunov wrote:
> Perhaps Victor and/or some other patch authors would assist.
I wish I could help you, but I am blocked from development on that branch as
well.
Victor Mote
all, please let me know (off-list), and I'll take a
look at your code and see if we can find a way to work together. The
splinters are sometimes necessary, but the fewer of them we have, the
better. I apologize that I haven't had time to look at your patch already.
Victor Mote
one reason I
went to this level of trouble is that I *think* it may help us in embedding
EPS files in PDF. If EPS graphics are being deprecated within the PDF
standard itself, that is of great interest.
Victor Mote
ould write a PDF "c" operator instead (I think -- they
look similar at first glance anyway). I think that should be a pretty good
way to proceed, but am interested in any comments.
Victor Mote
ctory.
I'll probably leave it alone until I need more from it, but I wanted to
update Jeremias and anyone else who is interested.
Victor Mote
any others who wrote the base code.
Victor Mote
Andreas L. Delmelle wrote:
> What about:
> - LayoutException
> - AreaException
> - RenderException
FWIW, this is exactly where FOray is headed. You and Finn are on the right
track.
Victor Mote
-caps can be achieved through your stylesheet. Use a different
font-family to point to the true small-caps font instead of
using font-variant."
It may also be worth announcing the doc change on fop-user. Let me know if
you have any questions. Thanks.
Victor Mote
he location
of the stylesheets as well (there is another entry later for the to-pdf
stylesheet). Find out where the equivalent sitemap for the new version is
and how to mimic the logic that is here.
That's about all I can think of to tell you. Good luck.
Victor Mote
think been well-enough tested), what
could be better than to have multiple successful open-source
implementations?
Victor Mote
veloper productivity) and to use "assert".
Victor Mote
xtension of the FOP website (and therefore referring to it for basics like
example), and it still has that perspective. Changing that to a turnkey
operation is one of the reasons FOray 0.2 has been delayed.
Victor Mote
Finn Bock wrote:
> I got some minor suggestions to the patch:
>
> - It should be strict typed: createBlock(..), createInline(..)
> - It should be complete so that all area creation was done through the
>factory, not just the 3 areas that Tibor needs.
Yes.
Victor Mote
elationships with the kind of
developers that you are going to need to finish this project. Makes no
difference to me. But, please, if you choose the former, send that promising
developer toward FOray -- I'm almost at the stage where I can drop in the
new layout system there. We'll find a place for good design ideas there.
Victor Mote
s. You might be interested in:
http://www.foray.org/goals.html#big
Victor Mote
'll
eventually invite the commercial developers too, if it looks like there is
anything here that helps.
Victor Mote
of aXSL (or vice versa), and I would be glad to have you
participate, when the appropriate time comes.
Victor Mote
o do the former, having the aXSL APIs in place would be a very
valuable tool in that process. I'll be glad to explain why when you are
ready to look at it, and perhaps I'll have something concrete (about the
abstractions :-) to show you by then as well. I'll be very happy to try to
coordinate this stuff so that we don't duplicate effort -- there has been
and will be too much of that as it is.
Victor Mote
except that: 1) FOray already
has the interface at least partially designed by virtue of isolating the PDF
code, and 2) making an interface *before* starting isolation work is a big
help in that work.
Victor Mote
ll be good for FOP's users, and
it should be good for FOP too. Essentially FOray can be testing and
improving these modules and interfaces while FOP works on the layout. Kind
of a competitive cooperation, or something like that.
Victor Mote
it may be good to find some variation, not only for
political reasons, but practical as well (cuts down on confusion). Maybe
something as simple as PFO, or maybe the aXSL name can help here.
I think you have done a good thing here.
Victor Mote
FOray ATM, you may get errors on properties, which is also
currently in an ugly state, half using the old scheme and half using the new
scheme. I am not aware of any actual errors ATM, but there almost certainly
are. My general advice would be to wait until I have it in a beta quality
state again,
has been pouring tirelessly in FOP,
> Batik, the XML federation and probably many things here that
> I don't know about.
Congratulations to Jeremias, the ASF, and FOP!
Victor Mote
ng able to demonstrate all of this within FOray,
but I am not sure whether I will get it done in time for the upcoming 0.2
release, although it will have an independent FOTree.
Victor Mote
ll handle all cases.
Victor Mote
layout), but the layout process is still sequential.
Perhaps we have a semantical misunderstanding here. By "see", I mean that we
know what is in it, and a multiple-pass solution can accomplish that. I'm
sure I acknowledged that as one of the two possibly ways that I could think
of to accomplish the end.
Victor Mote
ld request
> more child fo nodes, which the parser would provide on this demand.
>
> On Mon, Dec 13, 2004 at 08:29:43AM -0700, Victor Mote wrote:
> > Finn Bock wrote:
> >
> > > Did you notice that if a FOTree (or a fragment of it) is
> serialized
> > >
ished by caching it once at the top of the tree and using recursive
methods to get to it, so font-related services are pretty unobtrusive.
Victor Mote
t and look-ahead issues, but
I'll make them to you off-line, because I think the FOP folks don't want the
design conversations here.
My apologies for my part in starting this thread. Simon's original comment
could be interpreted in either a general or specific way, and I just wanted
to clarify that aspect of it. I didn't mean to start a debate at all.
Victor Mote
ieces were already in place, all I had to do was get the data stored and
retrieved correctly. Caveat: FOray stores and retrieves properties using a
late- or no-binding scheme, so the timing will be different, but I would
think the general principle would be the same.
HTH.
Victor Mote
Victor Mote wrote (on November 28, 2004):
> The code in the fop-maint branch is code that has not yet been peeled
> off into a FOray module. All of it eventually will be. The case of the
> "app"
> module, which will eventually contain the API that you are looking for
>
ded
dimension(s) back to it.
I HTH. It probably seems like I am beating a dead horse. That is not my
intention. I just think it has to be really frustrating to try to write
layout code when your FOTree and AreaTree issues are not resolved. I admire
those who try, but ...
Victor Mote
uch
viewport-area if the contents are too big to fit into one (subject to the
1.1 issue that you mention), but that, in any case, if the contents are too
small, the generated viewport-area must meet the IPD and BPD constraints.
The user can specify IPD and BPD as if they want to allow the
rectangle some flexibility in how it is sized.
HTH.
Victor Mote
90 degrees so that you can show, for example, a wide page in
landscape mode. You might want the contents to use the whole page, so
specifying the BPD/IPD allows you to insist upon that.
I'm not sure I am right about this, and don't mean to sound dogmatic. This
is just my understanding of the matter.
Victor Mote.
ing the entire contents
of both blocks, but that it would be pushed onto the following column/page.
Only if the contents didn't all fit into the first viewport would additional
ones be created (and then only if the overflow properties are set properly).
The user has dogmatically told us how big the viewport(s) should be.
Victor Mote
ft intact for the contents of
the block-container. So, if a decision has been made that an additional
viewport is needed to fit the contents, the keeps, breaks, and spaces would
be used to decide which content went to an anterior vp and which to a
posterior vp, just like in any page-break decision.
Victor Mote
Jeremias Maerki wrote:
> Thanks to Victor and Andreas for helping me here, although
> I'm still confused.
>
> On 27.01.2005 00:25:27 Victor Mote wrote:
> > Andreas L. Delmelle wrote:
> >
> > > Do you feel the contents of the block-container should
> n
very much on the right track here. One caveat: I
don't have all of my stuff working yet, so there may be a gotcha that I
haven't thought of.
If these comments are not helpful, please let me know. I don't mean to
generate noise -- I just like to support good ideas when I see them.
Victor Mote
o find his out-of-print books, please let us
know.
The general approach that FOray hopes to take eventually is a first-fit
algorithm for the initial pass through a page-sequence, then a second
optimization look that I hope to make do a Knuth-style evaluation. That may
be sub-optimal, but it is my
gress.
> Might these links help:
I think those are the "other" books, but, to tell the truth, after looking
at the links, I can't tell. I'll have to go dig out my old notes to see
which book I was wanting. I'll check into it further. Thanks.
Victor Mote
rd provides some guidance here, but I
agree that this part will be a challenge.
Good luck. I am glad to see you guys heading down this path. Let me know if
there is anything I can do to help.
Victor Mote
t for that. However, the standard has a way of humbling
me from time to time, so I may have missed it.
Victor Mote
is beneficial to cache the intermediate
computations for performance. It is not important to me ATM.
The ViewCVS of the classes mentioned is here:
http://cvs.sourceforge.net/viewcvs.py/foray/foray/foray-areatree/src/java/or
g/foray/area/
Victor Mote
I doubt
that I am the only subscriber to this list who was embarrassed by the
rudeness with which you were treated here.
Victor Mote
> conterpart of some fine chocolate :)
FOP 0.20.5 handles BMP images OK. Looking at the FOP trunk code right now,
there is a BmpImage class in package "image" and a BMPReader class in
image.analyzer, so I am not sure what you mean here.
Victor Mote
, or start a new
project that uses the aXSL interface. 5) If the aXSL interface is inadequate
and for any reason can't be changed, fork it and improve as necessary.
Such a scheme allows us to be optimistic that we will be able to work
together, but protects everybody in case we can't.
Victor Mote
on things with little to no potential for
> disagreements.
I think we can and should work together, but I see only downside potential
to making the relationship as tight as it once was. My philosophy makes
ample room for making mistakes ... once.
Victor Mote
upside is tremendous and the cost
pays for itself in developer productivity.
Victor Mote
tiple implementations that can be improved in parallel. However, I have a
great interest in your efforts, and will be glad to help any way that I can.
And, FWIW, I think you are on the right general track, in this regard at
least.
Victor Mote
ot so much the
algorithm. This is why I thought Finn's (IIRC) idea of a variable look-ahead
makes sense. A look-ahead of zero pages is a best-fit, a look-ahead of all
pages is a total-fit. But the algorithm is the same.
Anyway, I agree that the paper is probably the best source, but wanted to
give Jeremias some options.
Victor Mote
Victor Mote wrote:
> Oops. You're right. That is volume 2 from the same "Computers
> and Typesetting" series.
Er, it is actually volume B.
Victor Mote
he HEAD code is pretty similar to the maintenance branch code and
integration *should be* relatively easy. If improvements are made to the
HEAD code, then issues of merging, etc. crop up that make integration
difficult. That is OK too -- I just want to make sure that if it is done
that way, it is do
BPD of the block, do your copyfitting,
then come back and lay the block out properly later.
After thinking through all of these papers and ideas, I am more convinced
than ever of the utility of pluggable layout. But I guess you guys like
branches better :-)
Victor Mote
ught we were talking about total-fit. FOP 0.20.5 and Luca's
comments are both related to first-fit.
Victor Mote
eave it on
the back burner until someone sees a need for it.
Victor Mote
ypography" (Adobe Press)
has a lot of good information both for users and developers. Chapter 10 on
H&J was especially useful, and somewhat prompted the above questions.
Victor Mote (mailto:[EMAIL PROTECTED])
Enterprise Outfitters (www.outfitr.com)
2025 Eddington Way
Colorado Springs, Colo
bk" button by "No. 11" at
http://www.seyboldreports.com/SRPS/PSVOL22.HTM. I have ordered a copy.
Bringhurst also mentions a book published by URW -- HZ-program:
Micro-typography for Advanced Typesetting (Hamburg, 1993), which I have not
yet been able to locate.
Victor Mote
information at tug & ctan
licensing information, as well as in my Norman Walsh book "Making TeX Work".
Does it use a GPL? If it had a compatible licensing scheme, it would sure
seem to make sense to use as much of the TeX work as p
yet), but it is
possible that they have implemented some better H&J work.
I don't intend to implement any of this any time soon, but I need to let
some of the concepts sink in for a while, so I thought I had better get
started, in anticipation
to
http://www.ctan.org/tex-archive/help/Catalogue/entries/pdftex.html which
indicates that pdfTeX uses the GPL, so we may be out of luck there.
Victor Mote
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
it would seem
reasonable to distribute any remaining slack equally as space between the
leaders.
Victor Mote
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
nk it is worth exploring places
where we could unite development efforts. Perhaps some of the TeX guys that
follows this list would like to comment on this.
Victor Mote
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
be
either if we develop paragraph optimization. However, I could be wrong -- if
anyone thinks we should be concerned about it (legal exposure to Apache),
and knows what to do about it, please speak up. Otherwise, I think we just
useable state. Should we have yet another wiki to outline
all of this? Or is it premature to even discuss it much? Also, perhaps some
of it ties in with the wiki on resolution of breaks.
Victor Mote
-
To unsubscribe, e-mail: [EMAIL
Victor Mote wrote:
> Ek is actually hacking the font shapes. I have seen this or something
> similar done in FrameMaker, which gives the ability to stretch or condense
> glyphs on both the horizontal and vertical axes. However, FrameMaker also
> creates PDFs by generating Postscr
we consider the time saved by not needing to hyphenate so often
<-- End -->
For any who are interested in line-breaking, I highly recommend at least
reading through this material. The book has a lot of other interesting
things as well, including a chapter (4) on bidi.
I'm hoping to be ba
Oleg Tkachenko wrote:
> I've got this book too, good one, but too TeX-oriented IMO.
True enough that the book in general is TeX- & Metafont-oriented. However, I
thought the chapter on line-breaking was general enough to be very useful to
us.
gn, and frankly can't wait to
get back to it. This is not only an extraordinary project, but it has an
extraordinary crew (but let's don't ever do it this way again ... please).
Victor Mote
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Christian Geisert wrote:
> So I propose the following plan:
> Make another RC on february 17th and do the final 0.20.5 release
> on february the 28th (no delay except for very valid reasons)
>
> Comments?
+1
Victor Mote
-
o, if we build our own, we should credit Knuth & TeX, but also explicitly
reference the Apache license in the files, so that contributors know they
are contributing under that license.
Victor Mote
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
nd
inheritance. So, if we can hide all of the implementation details behind the
interface just as well as we can behind a facade, so that layout doesn't
know or care what kind of font it is dealing with, then we are OK. Ideally,
we want to do the same thing for the renderers, if possible.
Vic
1 - 100 of 496 matches
Mail list logo
