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
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
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
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
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!
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
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
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
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
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
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
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
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
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 |
-
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
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
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.
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
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
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
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
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.
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,
, 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
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
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
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
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
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.
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
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:
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
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
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
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
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
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
-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
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
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
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
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
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
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
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
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.
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
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
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
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
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.
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
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
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
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
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
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,
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
. 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
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
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
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
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
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
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
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
I personally would gladly work, but my brain no longer wants to. Guess I
need a break.
Vincent
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.
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.
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
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
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
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
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.
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).
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:
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
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.
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.
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
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
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
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
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
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
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
Hi Simon,
I finally took the time to read and digest your Wiki page. This is an
interesting reading. A few comments:
According to that representation paragraphs with inline text have
legal linebreak points. I consider those legal linebreak points also
as legal pagebreak points. In addition,
Author: jeremias
Date: Fri Sep 15 11:53:15 2006
New Revision: 446682
URL: http://svn.apache.org/viewvc?view=revrev=446682
Log:
mention that the config file format has changed.
snip/
+ If you are using a configuration file, you have rebuild it in the
new format. The format
A small
/
thanks,
Thang.
-Original Message-
From: Vincent Hennebert [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 05, 2006 5:06 PM
To: fop-users@xmlgraphics.apache.org
Subject: Re: FOP embed truetype font into postscript file
Nguyen, Thang a écrit :
Seem that a lots of works
Jeremias Maerki a écrit :
If anyone has any requirements for XSL-FO 2.0 which I should bring up at
the workshop in Heidelberg next week, please let me know. Deadline
2006-10-16 so I have time to prepare.
Jörg's comments just reminded me of something I think is missing in the
current spec:
Grmblbmlbbllbll. Forgot to change my Eclipse settings.
Sorry, won't happen again :-\
Vincent
Author: jeremias
Date: Wed Oct 11 07:30:34 2006
New Revision: 462814
URL: http://svn.apache.org/viewvc?view=revrev=462814
Log:
Tabs again. :-)
able too meet Vincent Hennebert in person in Amsterdam
last week. He has already made an impression with his excellent work for
the GSoC. He's a very nice and intelligent guy, eager to learn and to
work on FOP. Another guy who's not afraid to jump into the depths of the
layout engine.
Since
Hi all,
Sorry for the long post, but I think this is an important one.
I would like to have your feelings about the FOrayFont integration.
Since I started to work on that (in July 2005), things have quite
evolved and I'm starting to doubt that integrating FOrayFont really is a
good thing for
Jeremias Maerki a écrit :
Another of my travel projects checked in: I wanted to know how easy it
is to load fonts without the XML metrics file. As you can see from the
amount of code, it was rather easy. Makes me wonder why we didn't do it
earlier. :-)
Nice work, Jeremias. Well, definitely an
Hi all,
Just to let you know that I'd like to finish the implementation of the
collapsing border model.
I've started to look at the wiki pages, the code and the mail archives
but if you have any hint about what are the remaining problems to solve,
where to look at in particular, etc., I'm all
Hi guys,
As you may have noticed I have started to work on the table layout code.
For now I have just made some small improvements, mainly added javadoc
comments and renamed variables into names I believe are more explicit.
Please tell me if there are changes or javadoc comments you don't agree
Chris Bowditch a écrit :
Vincent Hennebert wrote:
Hi Bradley,
Bradley Harrington a écrit :
Hello,
I don't know if this is a known problem or not, however the
display-align attribute always puts the text at the top of the cell for
me. I have tried this with both trunk and 0.92 beta
Hi All,
So, not many opinions on this it seems. Thanks to Bertrand and Jeremias
for their comments.
I'll need to have a closer look at the current font library. As I was
supposed to replace it with FOrayFont I have never studied it in detail
yet. Then I'll see if it is best to keep it or to
Hi Luca,
Luca Furini a écrit :
snip/
1) TextLM breaks the text even when a / or a - is found, handling
them as hyphenation points with the usual sequence of glue + penalty +
glue elements.
The LineLM tries, in the first instance, to avoid using hyphenation
points, so the penalty is not
Hi guys,
J.Pietschmann a écrit :
Simon Pepping wrote:
Would this be a good moment to make these features of the breaking
algorithm user configurable, like they are in TeX? This allows people
to play with the various possibilities without having to modify the
code.
This can be combined with
1 - 100 of 801 matches
Mail list logo
