You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Victor Mote <vi...@outfitr.com> on 2003/01/28 16:43:37 UTC
source for hz algorithm
Hello all:
I have been looking for some time for a source for the HZ (Hermann Zapf)
algorithm which (as I understand) optimizes line breaks for multiple lines,
looking for rivers, too many lines in a row ending in hyphens, etc. I think
I first saw it referenced in Bringhurst's book, and that it was implemented
by a European company that is now out of business. I understand that TeX
implemented it or something similar, and that Adobe may have used the TeX
algorithm in InDesign. The closest thing I have found to a source for the
algorithm itself is that Knuth's "Digital Typography" may have it or at
least a discussion of it.
Do any of you have additional information on this, such as how to find the
algorithm itself? Is it patented?
Along these same lines, I recently acquired a book that may be helpful to
others -- James Felici's "The Complete Manual of Typography" (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:vic@outfitr.com)
Enterprise Outfitters (www.outfitr.com)
2025 Eddington Way
Colorado Springs, Colorado 80916
Voice +1 (719) 622-0650, Fax +1 (720) 293-0044
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: source for hz algorithm
Posted by "Peter B. West" <pb...@powerup.com.au>.
Clay Leeds wrote:
>>
>> Does the idea that there would be intermediate results mean that a
>> "human" could determine which is the best to perform the final layout?
>> I'm thinking of a system similar to how some OCR programs enable the
>> user to contribute to the process of recognition when the OCR program
>> has problems determining a word or character. (FYI: OCR=Optical
>> Character Recognition--used in scanning text-based documents which are
>> converted to text for archiving, indexing, etc.).
>>
>> If so, could the implementation offer some way of "saving" the best
>> method? I would think it would work like a userconfig file.
>
>
> I meant to add my reasoning. Since one can assume that generating
> multiple iterations will be processor intensive, if there existed some
> sort of "config" file identifying clues as to how the hz algorithm
> should proceed for a particular file, it would shorten the processing
> time, as well as ensure that the output was always the same.
>
Clay,
I don't see it this way. The multiple iterations occur within the
rendering of a particular document. I saw the human intervention as a
way of interactively deciding on one layout among a number of
possibilities which the processor was unable easily to distinguish, not
as some asynchronous event. While I can see the possibility of
"learning" about the scoring of layout possibilities from such
interactive input, I can't see that sets of rendering decisons need to
persist.
Peter
--
Peter B. West pbwest@powerup.com.au http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: source for hz algorithm
Posted by Clay Leeds <cl...@medata.com>.
Forgive the response to my own post...
Clay Leeds wrote:
> Peter B. West wrote:
>
>> Victor Mote wrote:
>>
>>> Peter B. West wrote:
>>>
>>>
>>>> These are interesting and important issues. I had no notion of the HZ
>>>> algorithm, but I was dimly aware from my reading as a teenager of the
>>>> "rivers" problem, and acutely conscious of its distracting effect from
>>>> my reading. In my thinking about layout, I have been conscious of the
>>>> need to be able to evaluate such issues at a high level. The only way
>>>> such an evaluation can be done is by layout look-ahead. The page must
>>>> be laid out before "rivers" can be assessed. (Finding them would be an
>>>> interesting problem in itself - and no doubt part of HZ.)
>>>
>>>
>>>
>>>
>>> It actually would seem to go beyond look-ahead, and instead be more
>>> along
>>> the lines of laying the content out multiple times & scoring each one.
>>
>>
>>
>> True, but I had in mind that any such approach will be built on the
>> fact that any layout is, in some sense, tentative. Rhett raised the
>> question some time ago of a means recording (and scoring) intermediate
>> results, something which will be an essential element of such a solution.
>>
>> At this stage, I would tend to think not of doing every possible
>> layout, but of following the "optimum" values to perform initial
>> layout, and then testing the result for "goodness". The
>> minimum-maximum range provides the slack - within the context of the
>> spec - for applying whatever other set of layout tuning algorithms
>> that FOP implements.
>>
>> I would see these being arranged as a set of heuristics - for want of
>> a better word - that are applied in a structured fashion to detected
>> layout conflicts of particular types. What comprises a conflict would
>> be determined by those configurable parameters.
>>
>> In the initial version, we only need to provide for the most basic of
>> these, as long as the mechanism is general enough to allow for
>> refinement.
>
>
> Does the idea that there would be intermediate results mean that a
> "human" could determine which is the best to perform the final layout?
> I'm thinking of a system similar to how some OCR programs enable the
> user to contribute to the process of recognition when the OCR program
> has problems determining a word or character. (FYI: OCR=Optical
> Character Recognition--used in scanning text-based documents which are
> converted to text for archiving, indexing, etc.).
>
> If so, could the implementation offer some way of "saving" the best
> method? I would think it would work like a userconfig file.
I meant to add my reasoning. Since one can assume that generating
multiple iterations will be processor intensive, if there existed some
sort of "config" file identifying clues as to how the hz algorithm
should proceed for a particular file, it would shorten the processing
time, as well as ensure that the output was always the same.
--
Clay Leeds - cleeds@medata.com
Web Developer - Medata, Inc. - http://www.medata.com
PGP Public Key: https://mail.medata.com/pgp/cleeds.asc
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: source for hz algorithm
Posted by "Peter B. West" <pb...@powerup.com.au>.
Clay Leeds wrote:
>
> Does the idea that there would be intermediate results mean that a
> "human" could determine which is the best to perform the final layout?
> I'm thinking of a system similar to how some OCR programs enable the
> user to contribute to the process of recognition when the OCR program
> has problems determining a word or character. (FYI: OCR=Optical
> Character Recognition--used in scanning text-based documents which are
> converted to text for archiving, indexing, etc.).
>
> If so, could the implementation offer some way of "saving" the best
> method? I would think it would work like a userconfig file.
>
Clay,
It's an interesting idea. It could be thought of as another User Agent
(or User Agency) function.
Peter
--
Peter B. West pbwest@powerup.com.au http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: source for hz algorithm
Posted by Clay Leeds <cl...@medata.com>.
Peter B. West wrote:
> Victor Mote wrote:
>
>> Peter B. West wrote:
>>
>>
>>> These are interesting and important issues. I had no notion of the HZ
>>> algorithm, but I was dimly aware from my reading as a teenager of the
>>> "rivers" problem, and acutely conscious of its distracting effect from
>>> my reading. In my thinking about layout, I have been conscious of the
>>> need to be able to evaluate such issues at a high level. The only way
>>> such an evaluation can be done is by layout look-ahead. The page must
>>> be laid out before "rivers" can be assessed. (Finding them would be an
>>> interesting problem in itself - and no doubt part of HZ.)
>>
>>
>>
>> It actually would seem to go beyond look-ahead, and instead be more along
>> the lines of laying the content out multiple times & scoring each one.
>
>
> True, but I had in mind that any such approach will be built on the fact
> that any layout is, in some sense, tentative. Rhett raised the question
> some time ago of a means recording (and scoring) intermediate results,
> something which will be an essential element of such a solution.
>
> At this stage, I would tend to think not of doing every possible layout,
> but of following the "optimum" values to perform initial layout, and
> then testing the result for "goodness". The minimum-maximum range
> provides the slack - within the context of the spec - for applying
> whatever other set of layout tuning algorithms that FOP implements.
>
> I would see these being arranged as a set of heuristics - for want of a
> better word - that are applied in a structured fashion to detected
> layout conflicts of particular types. What comprises a conflict would
> be determined by those configurable parameters.
>
> In the initial version, we only need to provide for the most basic of
> these, as long as the mechanism is general enough to allow for refinement.
Does the idea that there would be intermediate results mean that a
"human" could determine which is the best to perform the final layout?
I'm thinking of a system similar to how some OCR programs enable the
user to contribute to the process of recognition when the OCR program
has problems determining a word or character. (FYI: OCR=Optical
Character Recognition--used in scanning text-based documents which are
converted to text for archiving, indexing, etc.).
If so, could the implementation offer some way of "saving" the best
method? I would think it would work like a userconfig file.
--
Clay Leeds - cleeds@medata.com
Web Developer - Medata, Inc. - http://www.medata.com
PGP Public Key: https://mail.medata.com/pgp/cleeds.asc
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: source for hz algorithm
Posted by "Peter B. West" <pb...@powerup.com.au>.
Victor Mote wrote:
> Peter B. West wrote:
>
>
>>These are interesting and important issues. I had no notion of the HZ
>>algorithm, but I was dimly aware from my reading as a teenager of the
>>"rivers" problem, and acutely conscious of its distracting effect from
>>my reading. In my thinking about layout, I have been conscious of the
>>need to be able to evaluate such issues at a high level. The only way
>>such an evaluation can be done is by layout look-ahead. The page must
>>be laid out before "rivers" can be assessed. (Finding them would be an
>>interesting problem in itself - and no doubt part of HZ.)
>
>
> It actually would seem to go beyond look-ahead, and instead be more along
> the lines of laying the content out multiple times & scoring each one.
True, but I had in mind that any such approach will be built on the fact
that any layout is, in some sense, tentative. Rhett raised the question
some time ago of a means recording (and scoring) intermediate results,
something which will be an essential element of such a solution.
At this stage, I would tend to think not of doing every possible layout,
but of following the "optimum" values to perform initial layout, and
then testing the result for "goodness". The minimum-maximum range
provides the slack - within the context of the spec - for applying
whatever other set of layout tuning algorithms that FOP implements.
I would see these being arranged as a set of heuristics - for want of a
better word - that are applied in a structured fashion to detected
layout conflicts of particular types. What comprises a conflict would
be determined by those configurable parameters.
In the initial version, we only need to provide for the most basic of
these, as long as the mechanism is general enough to allow for refinement.
> One
> of the articles that Rhett pointed out indicates that Karow was working on a
> "chapter" level optimization -- probably equivalent to a page-sequence for
> us. It would seem easy to have several thousand or more possible layout
> options for an expanse that big.
>
> One issue in implementing this kind of thing is to make it configurable, or
> even to make specification part of the standard. A lot of on-the-fly
> web-based users won't want to spend the hardware resources to get output
> this finely tuned, but those of us who are generating high-quality static
> content won't mind. In other words, we need quick-and-dirty solutions that
> are optimized for speed to be able to coexist with more complex solutions
> that are optimized for quality. Part of what triggered my thoughts here was
> a thread on the XSL-FO list in which it was stated that XEP takes about 3
> times as long to run as FOP. There are a lot of possible reasons for this
> (including implementation of features that we don't have 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 of (hopefully) getting back into FOP code again
> within about a week.
--
Peter B. West pbwest@powerup.com.au http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: source for hz algorithm
Posted by Victor Mote <vi...@outfitr.com>.
Peter B. West wrote:
> These are interesting and important issues. I had no notion of the HZ
> algorithm, but I was dimly aware from my reading as a teenager of the
> "rivers" problem, and acutely conscious of its distracting effect from
> my reading. In my thinking about layout, I have been conscious of the
> need to be able to evaluate such issues at a high level. The only way
> such an evaluation can be done is by layout look-ahead. The page must
> be laid out before "rivers" can be assessed. (Finding them would be an
> interesting problem in itself - and no doubt part of HZ.)
It actually would seem to go beyond look-ahead, and instead be more along
the lines of laying the content out multiple times & scoring each one. One
of the articles that Rhett pointed out indicates that Karow was working on a
"chapter" level optimization -- probably equivalent to a page-sequence for
us. It would seem easy to have several thousand or more possible layout
options for an expanse that big.
One issue in implementing this kind of thing is to make it configurable, or
even to make specification part of the standard. A lot of on-the-fly
web-based users won't want to spend the hardware resources to get output
this finely tuned, but those of us who are generating high-quality static
content won't mind. In other words, we need quick-and-dirty solutions that
are optimized for speed to be able to coexist with more complex solutions
that are optimized for quality. Part of what triggered my thoughts here was
a thread on the XSL-FO list in which it was stated that XEP takes about 3
times as long to run as FOP. There are a lot of possible reasons for this
(including implementation of features that we don't have 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 of (hopefully) getting back into FOP code again
within about a week.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: source for hz algorithm
Posted by "Peter B. West" <pb...@powerup.com.au>.
Victor,
These are interesting and important issues. I had no notion of the HZ
algorithm, but I was dimly aware from my reading as a teenager of the
"rivers" problem, and acutely conscious of its distracting effect from
my reading. In my thinking about layout, I have been conscious of the
need to be able to evaluate such issues at a high level. The only way
such an evaluation can be done is by layout look-ahead. The page must
be laid out before "rivers" can be assessed. (Finding them would be an
interesting problem in itself - and no doubt part of HZ.)
Layout sometimes occurs in an environment of known available BPDimension
and IPDimension, sometimes with only one dimension, and sometimes with
neither. In the latter cases, the layout process is effectively a probe
to see what the dimensional requirements range for this piece of layout
is. However, problems like rivers, last page and footnotes turn all
layout into probes, and all layout must potentially be undone and redone
in the light of the knowledge gained.
Peter
Victor Mote wrote:
> Hello all:
>
> I have been looking for some time for a source for the HZ (Hermann Zapf)
> algorithm which (as I understand) optimizes line breaks for multiple lines,
> looking for rivers, too many lines in a row ending in hyphens, etc. I think
> I first saw it referenced in Bringhurst's book, and that it was implemented
> by a European company that is now out of business. I understand that TeX
> implemented it or something similar, and that Adobe may have used the TeX
> algorithm in InDesign. The closest thing I have found to a source for the
> algorithm itself is that Knuth's "Digital Typography" may have it or at
> least a discussion of it.
>
> Do any of you have additional information on this, such as how to find the
> algorithm itself? Is it patented?
>
> Along these same lines, I recently acquired a book that may be helpful to
> others -- James Felici's "The Complete Manual of Typography" (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:vic@outfitr.com)
> Enterprise Outfitters (www.outfitr.com)
> 2025 Eddington Way
> Colorado Springs, Colorado 80916
> Voice +1 (719) 622-0650, Fax +1 (720) 293-0044
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
>
--
Peter B. West pbwest@powerup.com.au http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: source for hz algorithm
Posted by "Peter B. West" <pb...@powerup.com.au>.
Sebastian Rahtz (PassiveTeX) would be a good source of information. I
think he tends to hang around on www-xsl-fo@w3.org.
Btw, URW provide one of the best-known set of free Type1 fonts for linux.
Peter
Victor Mote wrote:
> J.Pietschmann wrote:
>
>
>>The TeX-Book has a chapter about this problem. It is available
>>as textbook.tex (in TeX, and quite officially). Amazingly, I
>>didn't find it on CTAN, but a google search turns up other
>>servers (I can send you the 460k compressed source).
>
>
> I think it is also Volume A of Knuth's "Computers & Typesetting", which I
> hope to receive shortly. I am hoping not to have to stop and become a TeX
> user along the way, but I think it is worth learning as much as is morally
> possible from them.
>
> BTW, I looked for but did not find licensing 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 possible.
--
Peter B. West pbwest@powerup.com.au http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: source for hz algorithm
Posted by Victor Mote <vi...@outfitr.com>.
Ralph LaChance wrote:
> I'm puzzled how they can own a patent on an algorithm stated years
> ago and summarized in a european student's thesis. But then I don'w
> know about these things ;-)
I am under the impression that hz-program and pdfTeX were basically
independent efforts, probably with some cross-pollinization. I'm no expert
on this, but I don't think anyone could patent the general idea of paragraph
optimization, but only perhaps(!) a specific algorithm or implementation of
doing so. So I doubt that pdfTeX is in danger, and I doubt that we will 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
keep plodding along.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: source for hz algorithm
Posted by Ralph LaChance <Ra...@compuserve.com>.
At 12:51 AM 1/31/2003, you wrote:
>I made an inquiry on URW's web site yesterday, and received a response
>today. The short story is that what I had inferred from the postings on
>other lists is correct: the patent to hz-program is now owned by Adobe, and
>is probably the basis for their paragraph-level formatting in InDesign. So
>to summarize:
I'm puzzled how they can own a patent on an algorithm stated years
ago and summarized in a european student's thesis. But then I don'w
know about these things ;-)
' Best,
-Ralph LaChance
In theory, there is no difference between
theory and practice, but in practice there is.
(Jan L.A. van de Snepsheut (1953-1994), late of CalTech)
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: source for hz algorithm
Posted by Victor Mote <vi...@outfitr.com>.
I made an inquiry on URW's web site yesterday, and received a response
today. The short story is that what I had inferred from the postings on
other lists is correct: the patent to hz-program is now owned by Adobe, and
is probably the basis for their paragraph-level formatting in InDesign. So
to summarize:
- hz-program is not accessible to us (patented)
- pdfTeX is not accessible to us (GPL)
- I will try to learn what I can from the Knuth, Karow, and Seybold
documents & let you know whether there is anything useful in them
- I think we should feel free to learn whatever we can from TeX. In fact,
I think it might be a worthwhile effort to see whether some of the TeX
developers wouldn't want to join our effort. As far as I can tell, we're
working on the same project with different input syntax. I wouldn't want to
take developers away from TeX, but I think 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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: source for hz algorithm
Posted by Victor Mote <vi...@outfitr.com>.
Sébastien Aperghis-Tramoni wrote:
> Information about the licenses used by the TeX related softwares
> are available on this page:
> http://www.ctan.org/tex-archive/help/Catalogue/licenses.html
>
> The core of TeX, the files written by Donald Knuth, doesn't seem to
> be covered by a particular license apart from the README file
> http://www.ctan.org/tex-archive/systems/knuth/tex/README
>
> The TeX FAQ confirms that TeX simply is free:
> http://www.tex.ac.uk/cgi-bin/texfaq2html?label=whyfree
Thanks very much for digging those out. The last one describes what seems a
lot like the Apache license -- in other words, there don't seem to be
restrictions on commercial use. From what I have read so far, pdfTeX is the
implementation that uses the HZ stuff (or something similar) most heavily.
Digging through the first reference above led me 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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: source for hz algorithm
Posted by Sébastien Aperghis-Tramoni <ma...@free.fr>.
On Wednesday, January 29, 2003, at 09:05 AM, Victor Mote wrote:
> BTW, I looked for but did not find licensing 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 possible.
Information about the licenses used by the TeX related softwares
are available on this page:
http://www.ctan.org/tex-archive/help/Catalogue/licenses.html
The core of TeX, the files written by Donald Knuth, doesn't seem to
be covered by a particular license apart from the README file
http://www.ctan.org/tex-archive/systems/knuth/tex/README
The TeX FAQ confirms that TeX simply is free:
http://www.tex.ac.uk/cgi-bin/texfaq2html?label=whyfree
Sébastien Aperghis-Tramoni
-- - --- -- - -- - --- -- - --- -- - --[ http://maddingue.org ]
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: source for hz algorithm
Posted by Victor Mote <vi...@outfitr.com>.
J.Pietschmann wrote:
> The TeX-Book has a chapter about this problem. It is available
> as textbook.tex (in TeX, and quite officially). Amazingly, I
> didn't find it on CTAN, but a google search turns up other
> servers (I can send you the 460k compressed source).
I think it is also Volume A of Knuth's "Computers & Typesetting", which I
hope to receive shortly. I am hoping not to have to stop and become a TeX
user along the way, but I think it is worth learning as much as is morally
possible from them.
BTW, I looked for but did not find licensing 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 possible.
Thanks for the information.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: source for hz algorithm
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Victor Mote wrote:
> I have been looking for some time for a source for the HZ (Hermann Zapf)
> algorithm which (as I understand) optimizes line breaks for multiple lines,
The TeX-Book has a chapter about this problem. It is available
as textbook.tex (in TeX, and quite officially). Amazingly, I
didn't find it on CTAN, but a google search turns up other
servers (I can send you the 460k compressed source).
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: source for hz algorithm
Posted by Victor Mote <vi...@outfitr.com>.
Dirk-Willem van Gulik wrote:
> It is documented in either book 1 or 2 of Digital Typography by (I think!)
> P. Karow, of URW (i.e. the folks behind the Ikarus format (just google
> for URW and Digital Typograhy or Ikarus)). I think it is in book one. The
> books are an absolute 'must have' - but hard to get. Occasionally one can
> be found second hand; usually from a art/font firm dealing with the
> high end market of posters and other big print publications.
>
> But the algorithm described there is not a computer one; but more a method
> for someone cutting the scripts coming out of the linotypes and pasting
> them on the wax board.
I guess I am confused. The HZ algorithm is AFAIK a computer algorithm, or at
least a mathematical one that can be implemented by a computer. I don't
think it could be applied to a linotype at all, as that would be working
with only one line of text at a time (I'm in over my head, barely knowing
what a linotype is). Line-by-line breaking is what most word processors do,
and what FOP currently does. HZ definitely looks at a bigger context --
either whole paragraphs or a fixed window of a quantity of lines. So I
wonder whether we are talking about the same thing. I see Rhett's post that
he has found a copy of the books, so perhaps we can figure out a way to
check for sure. Thanks for the info!
I must admit to being a bit humbled. I have shopped for font editing
software at least twice, and never stumbled across URW, and have never heard
of Ikarus before.
I see also now in Bringhurst that he mentions the Seybold Report on
Publishing Systems 22.11 as a source of information on this subject. A hard
copy can be ordered for $25 ($20 if you are a Seybold subscriber) by
pressing the "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
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: source for hz algorithm
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On Tue, 28 Jan 2003, Victor Mote wrote:
> I have been looking for some time for a source for the HZ (Hermann Zapf)
> algorithm which (as I understand) optimizes line breaks for multiple lines,
> looking for rivers, too many lines in a row ending in hyphens, etc. I think
> I first saw it referenced in Bringhurst's book, and that it was implemented
> by a European company that is now out of business. I understand that TeX
> implemented it or something similar, and that Adobe may have used the TeX
> algorithm in InDesign. The closest thing I have found to a source for the
> algorithm itself is that Knuth's "Digital Typography" may have it or at
> least a discussion of it.
It is documented in either book 1 or 2 of Digital Typography by (I think!)
P. Karow, of URW (i.e. the folks behind the Ikarus format (just google
for URW and Digital Typograhy or Ikarus)). I think it is in book one. The
books are an absolute 'must have' - but hard to get. Occasionally one can
be found second hand; usually from a art/font firm dealing with the
high end market of posters and other big print publications.
But the algorithm described there is not a computer one; but more a method
for someone cutting the scripts coming out of the linotypes and pasting
them on the wax board.
Dw.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org