You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by Julian Reschke <ju...@gmx.de> on 2003/08/09 23:38:24 UTC
0.20.5 vs hyphenation
Hi.
I think the non-letter handling in LineArea's hyphenation routine needs to
enhanced.
I'm producing a two-column index which contains keywords from WebDAV specs,
such as "DAV:version-controlled-collection", i.e. the words contain multiple
non-letter characters.
The current implementation seems to have two limitations:
- if a non-letter character other than "/" and "-" is found, the whole word
isn't hyphenated at all.
- the code that tries to identify "-"-separated word parts does this only
once instead of continuing until no space is left.
The result is words like the example above aren't hyphenated at all, and
that words like "version-controlled-collection" will always be hyphenated
after the first minus sign, even if there would have been enough room for
more.
I'm currently testing a patch than changes this to:
- accept *all* non-letter characters as possible hyphenation points,
- continue scanning the word after the first non-letter char was found, and
- add a single hyphenation character if hyphenation occurs at a non-letter
character other than "-".
This seems to work fine for my test cases.
As I'm new to this list I wonder how to proceed? Should I raise a bug and
post the patch?
Julian
(patch attached)
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: 0.20.5 vs hyphenation
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Julian Reschke wrote:
> I think the non-letter handling in LineArea's hyphenation routine needs to
> enhanced.
A lot of people think so. The bad news is that this is the wrong
approach.
There is a relevant standard which guides line breaking: Unicode
UAX#14. Implementing it would take care of your problem as well
as of "hyphenation" for far east languages and a few other things.
The obstacles are 1. the line breaking code in the maintenance
branch is ... messy, and it wont be updated anyway and 2. grokking
UAX#14 requires swapping everything out of your brain, including
the names of your spouse and your cat, and generally doesn't work
well in warm weather.
The next problem is the hyphenation algorithm itself. Problem
zones:
- Gathering characters into words for hyphenation. This should
be controlled by the hyphenator, but it isn't.
- Character normalization. Look into the relevant report.
- Incremental pattern matching for sort of parallel hyphenation,
resulting in proper handling of spelling changing exceptions
without much overhead.
Contributions are welcome.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-user-unsubscribe@xml.apache.org
For additional commands, e-mail: fop-user-help@xml.apache.org
RE: 0.20.5 vs hyphenation
Posted by Julian Reschke <ju...@gmx.de>.
> From: Glen Mazza [mailto:grm7793@yahoo.com]
> Sent: Sunday, August 10, 2003 3:58 PM
> To: fop-user@xml.apache.org
> Subject: Re: 0.20.5 vs hyphenation
>
>
> --- Julian Reschke <ju...@gmx.de> wrote:
> > The current implementation seems to have two
> > limitations:
> >
> > - if a non-letter character other than "/" and "-"
> > is found, the whole word
> > isn't hyphenated at all.
> >
>
> Which would actually be good in the case of a http://
> URL, correct? In other words, if we made this change,
> wouldn't we end up getting complaints that
> "www.someURL.com" is being broken up and hyphenated
> (and perhaps linking properties lost)?
Yes. But the issue that got me where I am right now is that the word
*itself* doesn't fit into the line. Currently, fop handles this either by
just overflowing the area, or by breaking the word without hyphenating it.
What it doesn't do is to break the word where the "-" character already is
in.
So maybe my change should only be active when this is the first word on the
line.
> We have to be careful that majority cases are properly
> handled: DAV:one-two-three is used less often than
> "http://www.someURL.com" (or "www.someURL.com") in
> text, and so the proper handling of the latter should
> take precedence.
Yes. But what *is* proper handling here? Currently, FOP just gives up,
producing extremely ugly output, while other engines (such as RenderX and
AntennaHouse) just hyphenate the word.
> > I'm currently testing a patch than changes this to:
> >
> > - continue scanning the word after the first
> > non-letter char was found, and
> >
>
> This one may be a good idea.
>
> >
> > As I'm new to this list I wonder how to proceed?
> > Should I raise a bug and
> > post the patch?
> >
>
> Yes, please post it to Bugzilla (we may not have time
> to get to it for awhile though...), *but* using "diff
> -u" option so we see the +'s and -'s changes in the
> first column. Also make sure you list in the bug
> description text the "before" functionality and the
> "after" functionality (as you did above) so other
> users/developers can comment on the proposed changes
> in business rules.
OK, let's discuss what we *want* it to do, and then I'll make the bug report
/ change request.
Julian
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-user-unsubscribe@xml.apache.org
For additional commands, e-mail: fop-user-help@xml.apache.org
RE: fox:destination
Posted by Victor Mote <vi...@outfitr.com>.
Julian Reschke wrote:
> here's a very short description for "extensions.xml":
OK, I have added this to CVS, along with a few embellishments. It should be
live on the site within a few days. Again, thanks for pointing this out and
helping to get it documented.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-user-unsubscribe@xml.apache.org
For additional commands, e-mail: fop-user-help@xml.apache.org
RE: fox:destination
Posted by Julian Reschke <ju...@gmx.de>.
Ok,
here's a very short description for "extensions.xml":
cvs server: Diffing .
Index: extensions.xml
===================================================================
RCS file:
/home/cvspublic/xml-fop/src/documentation/content/xdocs/extensions.xml,v
retrieving revision 1.3.2.3
diff -r1.3.2.3 extensions.xml
52a51,62
> </section>
> <section id="named-destinations">
> <title>Setting anchors</title>
> <p>
> This extension allows to define "named destinations" inside the PDF
document.
> They can be used as fragment identifiers, such as in
"http://server/document.pdf#anchor-name".
> </p>
> <source>
> <![CDATA[
> <fox:destination xmlns:fox="http://xml.apache.org/fop/extensions"
> internal-destination="anchor-name"/>
> ]]></source>
Regards, Julian
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent: Monday, August 11, 2003 11:28 AM
> To: fop-user@xml.apache.org
> Subject: RE: fox:destination
>
>
> > From: Victor Mote [mailto:vic@outfitr.com]
> > Sent: Monday, August 11, 2003 8:31 AM
> > To: fop-user@xml.apache.org
> > Subject: RE: fox:destination
> >
> >
> > Julian Reschke wrote:
> >
> > > while browsing the source of the maintenance branch I found
> out that FOP
> > > already has support for creating anchors within PDF files
> > (things that can
> > > be addressed using URL fragment identifiers). It seems that?it
> > works just
> > > fine.
> > >
> > > Why is this missing from the documentation?
> >
> > If you are saying that there is a fox:destination extension that creates
> > named destinations in a PDF, then the reason that *I* haven't
> documented it
> > is that I didn't know about it. However, there is, IMO, another problem
>
> It has been added in February:
>
> "Added new extension element for defining named destinations (PDF)
> Submitted by: Lloyd McKenzie <lm...@ca.ibm.com> and Stefan Wachter"
>
> > here, and that is that I don't think that should be an
> extension, but should
> > work off of the "id" attribute. Right now "id"s can be targets,
> but AFAIK
> > they don't create named destinations. I can't think of a good reason why
> > targets shouldn't be named destinations, so that two birds are
> killed with
> > one stone. I suppose there might be some file size advantage in some
>
> Actually I absolutely agree here.
>
> > situations, so maybe it should be configurable. I suppose that
> any changes
> > will need to be in the redesign, and that we should just document the
> > existing behavior for now.
>
> Right.
>
> > At any rate, if you'll write something up and post it, I'll
> test it and get
> > it into the doc. Thanks for pointing this out.
>
> OK, I'll try.
>
> Julian
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
RE: fox:destination
Posted by Julian Reschke <ju...@gmx.de>.
> From: Victor Mote [mailto:vic@outfitr.com]
> Sent: Monday, August 11, 2003 8:31 AM
> To: fop-user@xml.apache.org
> Subject: RE: fox:destination
>
>
> Julian Reschke wrote:
>
> > while browsing the source of the maintenance branch I found out that FOP
> > already has support for creating anchors within PDF files
> (things that can
> > be addressed using URL fragment identifiers). It seems that?it
> works just
> > fine.
> >
> > Why is this missing from the documentation?
>
> If you are saying that there is a fox:destination extension that creates
> named destinations in a PDF, then the reason that *I* haven't documented
it
> is that I didn't know about it. However, there is, IMO, another problem
It has been added in February:
"Added new extension element for defining named destinations (PDF)
Submitted by: Lloyd McKenzie <lm...@ca.ibm.com> and Stefan Wachter"
> here, and that is that I don't think that should be an extension, but
should
> work off of the "id" attribute. Right now "id"s can be targets, but AFAIK
> they don't create named destinations. I can't think of a good reason why
> targets shouldn't be named destinations, so that two birds are killed with
> one stone. I suppose there might be some file size advantage in some
Actually I absolutely agree here.
> situations, so maybe it should be configurable. I suppose that any changes
> will need to be in the redesign, and that we should just document the
> existing behavior for now.
Right.
> At any rate, if you'll write something up and post it, I'll test it and
get
> it into the doc. Thanks for pointing this out.
OK, I'll try.
Julian
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-user-unsubscribe@xml.apache.org
For additional commands, e-mail: fop-user-help@xml.apache.org
RE: fox:destination
Posted by Victor Mote <vi...@outfitr.com>.
Julian Reschke wrote:
> while browsing the source of the maintenance branch I found out that FOP
> already has support for creating anchors within PDF files (things that can
> be addressed using URL fragment identifiers). It seems that?it works just
> fine.
>
> Why is this missing from the documentation?
If you are saying that there is a fox:destination extension that creates
named destinations in a PDF, then the reason that *I* haven't documented it
is that I didn't know about it. However, there is, IMO, another problem
here, and that is that I don't think that should be an extension, but should
work off of the "id" attribute. Right now "id"s can be targets, but AFAIK
they don't create named destinations. I can't think of a good reason why
targets shouldn't be named destinations, so that two birds are killed with
one stone. I suppose there might be some file size advantage in some
situations, so maybe it should be configurable. I suppose that any changes
will need to be in the redesign, and that we should just document the
existing behavior for now.
At any rate, if you'll write something up and post it, I'll test it and get
it into the doc. Thanks for pointing this out.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-user-unsubscribe@xml.apache.org
For additional commands, e-mail: fop-user-help@xml.apache.org
fox:destination
Posted by Julian Reschke <ju...@gmx.de>.
Hi,
while browsing the source of the maintenance branch I found out that FOP
already has support for creating anchors within PDF files (things that can
be addressed using URL fragment identifiers). It seems that?it works just
fine.
Why is this missing from the documentation?
Julian
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-user-unsubscribe@xml.apache.org
For additional commands, e-mail: fop-user-help@xml.apache.org
Re: 0.20.5 vs hyphenation
Posted by Glen Mazza <gr...@yahoo.com>.
--- Julian Reschke <ju...@gmx.de> wrote:
> The current implementation seems to have two
> limitations:
>
> - if a non-letter character other than "/" and "-"
> is found, the whole word
> isn't hyphenated at all.
>
Which would actually be good in the case of a http://
URL, correct? In other words, if we made this change,
wouldn't we end up getting complaints that
"www.someURL.com" is being broken up and hyphenated
(and perhaps linking properties lost)?
We have to be careful that majority cases are properly
handled: DAV:one-two-three is used less often than
"http://www.someURL.com" (or "www.someURL.com") in
text, and so the proper handling of the latter should
take precedence.
>
> I'm currently testing a patch than changes this to:
>
> - continue scanning the word after the first
> non-letter char was found, and
>
This one may be a good idea.
>
> As I'm new to this list I wonder how to proceed?
> Should I raise a bug and
> post the patch?
>
Yes, please post it to Bugzilla (we may not have time
to get to it for awhile though...), *but* using "diff
-u" option so we see the +'s and -'s changes in the
first column. Also make sure you list in the bug
description text the "before" functionality and the
"after" functionality (as you did above) so other
users/developers can comment on the proposed changes
in business rules.
Thanks,
Glen
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-user-unsubscribe@xml.apache.org
For additional commands, e-mail: fop-user-help@xml.apache.org