On Fri, Jun 27, 2014 at 08:06:38PM +0200, Steffen Nurpmeso wrote:
> Hello Ulrich,
>
[ ... ]
> (But again, i personally never had a problem with the typesetting
> quality of troff (with the TeX-borrowed German hyphenation
> enabled), proof-reading provided -- the German translation of
> K & R "Prog
Hello Ulrich,
Ulrich Lauther wrote:
|On Fri, Jun 27, 2014 at 03:43:24PM +0200, Steffen Nurpmeso wrote:
|> Oh, after fiddling with unsupported linker options etc. to compile
|> the showcase i got a SIGBUS. You know, as in "Bus stop, wet day,
|> she's there" etc. Only the umbrella is still mi
On Fri, Jun 27, 2014 at 03:43:24PM +0200, Steffen Nurpmeso wrote:
>
> Oh, after fiddling with unsupported linker options etc. to compile
> the showcase i got a SIGBUS. You know, as in "Bus stop, wet day,
> she's there" etc. Only the umbrella is still missing.
> Ciao,
>
> --steffen
Not clear to
Hello Ralph,
Ralph Corderoy wrote:
|Hi Steffen,
|
|>> The closest is
|>> http://www.iana.org/assignments/media-types/application/gzip which
|>> leaves the tar for the user to fathom out if left to MIME types
|>> alone.
|>
|> [http://svn.apache.org/viewvc/tika/trunk/tika-core/src/ma\
|> i
Hi Steffen,
> > The closest is
> > http://www.iana.org/assignments/media-types/application/gzip which
> > leaves the tar for the user to fathom out if left to MIME types
> > alone.
>
> [http://svn.apache.org/viewvc/tika/trunk/tika-core/src/main/resources/org/apache/tika/mime/tika-mimetypes.xml]
>
Hello Ralph,
Ralph Corderoy wrote:
|Hi Peter,
|
|>> http://lists.gnu.org/archive/html/groff/2014-06/bin14bGZPiUPU.bin
|>> which
|>
|> The .bin extension issue for attachments in archived email has come up
|> before. Does anyone know why lists.gnu.org is doing this and whether
|> there'd
Hi Peter,
> > http://lists.gnu.org/archive/html/groff/2014-06/bin14bGZPiUPU.bin
> > which
>
> The .bin extension issue for attachments in archived email has come up
> before. Does anyone know why lists.gnu.org is doing this and whether
> there'd be any point trying to get it fixed?
It's to prot
In the meantime I have send the tgz-file directly to Dough, not to the list,
and he was able to read it.
Waiting for comments,
ulrich
On Thu, Jun 26, 2014, Ralph Corderoy wrote:
> When I view Ulrich's email at
> http://lists.gnu.org/archive/html/groff/2014-06/msg00089.html I see a
> distribute.tgz link at the end of it to
> http://lists.gnu.org/archive/html/groff/2014-06/bin14bGZPiUPU.bin which
> works for me.
The .bin extension
Hi Doug,
> Ulrich wrote, "Please find below ... my attached code."
>
> gnu.org reports "not found" for the strange-looking URL where the
> attachment was supposedly stored:
> http://lists.gnu.org/archive/html/groff/attachments/20140623/d3f40bfc/attachment.bin
The email I received from the list h
Ulrich wrote, "Please find below ... my attached code."
gnu.org reports "not found" for the strange-looking URL where the
attachment was supposedly stored:
http://lists.gnu.org/archive/html/groff/attachments/20140623/d3f40bfc/attachment.bin
On Wed, May 28, 2014, Ulrich Lauther wrote:
> I think, the experiment shows that running time is no issue at all.
This is terrific news. One of groff's greatest strengths is speed. It
will be wonderful if improved formatting can be achieved with no
loss in that department. Thanks, Ulrich, for t
On Mon, Mar 31, 2014 at 07:44:07PM -0400, Peter Schaffter wrote:
> Here's the bare bones version of the algorithm I was thinking of
> when I proposed improving line formatting by getting groff to
> shoulder the burden for some of the work we do manually. It's
> written out in brute-force pseudo-co
On Sun, May 04, 2014 at 02:59:19PM -0400, Doug McIlroy wrote:
> > I don't see why any forking should be needed.
>
> I am all ears. I'd love to know a better way to cope with events
> that are triggered by line breaks, when several different potential
> line breaks are in play, as were discussed i
James --
On Sun, May 04, 2014, James K. Lowden wrote:
> Are you really concerned about minimal resource requirements, or
> speed of processing?
You're quite right, the issue is speed.
> Doug's description retains a one-pass algorithm, which is key for
> speed. A parallel approach (forking) will
On Sat, 3 May 2014 14:23:10 -0400
Peter Schaffter wrote:
> > A straightforward way to pull this off would be to actualize the
> > notional copies of groff by forking. There would be one copy going
> > forward from each line break. That would evaluate the cost of
> > breaking at each word (or hyph
> I don't see why any forking should be needed.
I am all ears. I'd love to know a better way to cope with events
that are triggered by line breaks, when several different potential
line breaks are in play, as were discussed in my posting to which
Peter's referred. Forking is certainly unappealing
On Sat, May 03, 2014 at 02:23:10PM -0400, Peter Schaffter wrote:
>
> I suspect I'm a voice crying in the wilderness here, but we need to
> consider that a greedy algorithm is almost always faster than a
> dynamic programming solution; furthermore, greedy algorithms
> sometimes lead to optimal solu
On Fri, Apr 25, 2014, Doug McIlroy wrote:
> Equations and displayed quotations are not a problem for the line-breaking
> algorithm; they'd all be handled in the macro packages, which would have
> the duty to delimit the blocks of text that are to be treated unitarily.
>
> But that doesn't mean we'
Equations and displayed quotations are not a problem for the line-breaking
algorithm; they'd all be handled in the macro packages, which would have
the duty to delimit the blocks of text that are to be treated unitarily.
But that doesn't mean we're home free. Line-length changes within such
blocks
On Thu, Apr 24, 2014, Ulrich Lauther wrote:
> > Any time you introduce a break, even within a logical paragraph, the
> > preceding text needs to be adjusted. I can't see any advantage to
> > including the text after an in-paragraph insertion in the adjustment
> > process,
>
> Yes, the preced
Hi Ulrich,
> Yes, the preceding text needs to be adjusted. But why shouldn't the
> adjustment algorithm when working on one "physical paragraph" be
> allowed to "steal" one or more words from the next physical part of
> the logical paragraph.
Because the inserted equation or quote needs to be pre
On 23/04/14 22:42, (Ted Harding) wrote:
> I think some confusion is possibly arising here. See in-line below.
>
> On 23-Apr-2014 20:45:10 Keith Marshall wrote:
>> Doesn't a paragraph logically conclude at any request which introduces a
>> break? Or invocation of any macro which itself invokes suc
Peter Schaffter wrote:
|BTW--does anyone know how KP/TeX handles paragraphs with "spread"
|(.brp) lines?
\def\@fillbr{\ifvmode\else\unskip\hfill\penalty-1\fi\relax}%
\def\@nofillbr{\ifvmode\else\penalty-1\fi\relax}%
% ('\\' is redefined in some envs)
\let\\\@fillbr%
\def\br{\\
On Wed, Apr 23, 2014 at 07:30:34PM -0400, Peter Schaffter wrote:
> On Wed, Apr 23, 2014, Ted Harding wrote:
> > I think some confusion is possibly arising here. See in-line below.
> >
> > > Doesn't a paragraph logically conclude at any request which introduces a
> > > break? Or invocation of any m
> BTW--does anyone know how KP/TeX handles paragraphs with "spread"
> (.brp) lines?
You simply insert
\penalty -1
to force a line break at this very place (while still retaining
justification).
On the other hand, the equivalent to `.br' (and the end of a
paragraph) is to insert an infin
Hi Ted,
> I think I have to disagree here. For example, in the middle of a
> paragraph I may wish to put some text centred on lines by itself, and
> this may be in the middle of a sentence -- perhaps a parenthetical
> quotation. Or, in technical writing, a displayed equation in the
> middle of a s
On Wed, Apr 23, 2014, Ted Harding wrote:
> I think some confusion is possibly arising here. See in-line below.
>
> > Doesn't a paragraph logically conclude at any request which introduces a
> > break? Or invocation of any macro which itself invokes such a request?
> > (In addition to an empty inp
Keith --
On Wed, Apr 23, 2014, Keith Marshall wrote:
> > Signalling the end of collected paragraphs can't be done exclusively
> > within macros because, unlike SGMLs, paragraph macros in groff
> > generally aren't closed.
>
> Doesn't a paragraph logically conclude at any request which introduces
I think some confusion is possibly arising here. See in-line below.
On 23-Apr-2014 20:45:10 Keith Marshall wrote:
> On 22/04/14 20:40, Peter Schaffter wrote:
>> On Tue, Apr 22, 2014, Ulrich Lauther wrote:
>>> Well of course not. A paragraph ends, e.g. when an empty line is
>>> seen. Probably the
On 22/04/14 20:40, Peter Schaffter wrote:
> On Tue, Apr 22, 2014, Ulrich Lauther wrote:
>> Well of course not. A paragraph ends, e.g. when an empty line is
>> seen. Probably there are a whole lot of other conditions. My
>> understanding is that formatting takes place after macros have
>> been ex
On Tue, Apr 22, 2014, Ulrich Lauther wrote:
> Well of course not. A paragraph ends, e.g. when an empty line is
> seen. Probably there are a whole lot of other conditions. My
> understanding is that formatting takes place after macros have
> been expanded; at the macro level it would be easier.
On Tue, Apr 22, 2014 at 12:04:27PM -0400, Peter Schaffter wrote:
> Ulrich --
> > But maybe just implementing "read NextWord" is the difficulty?
>
> After adjusting and breaking a line, groff holds remaining
> input-line text as a partially-filled line, so reading NextWord is
> at least theoretical
Ulrich --
On Mon, Apr 14, 2014, Ulrich Lauther wrote:
> On Mon, Apr 14, 2014 at 12:41:56PM +0100, Ralph Corderoy wrote:
> > Hi Ulrich,
> >
> > > Even if a greedy algorithm will be implemented, it should have the
> > > whole paragraph available as input. That way, one could easily switch
> > > ov
Whatever you do, don't do what Microsoft and relatives do by *assuming*
a block of text in one line is a paragraph, and you can't write a
paragraph as a series of shorter single lines.
Word was written for idiots who don't want to learn anything they don't
have to, and it drives me nuts!
I do al
Brave statement -- good luck!
Unlike TeX, troff has no modes, so a method of delimiting a paragraph has to
be introduced. Text outside would be treated as currently, text inside would
be subject to whatever algorithm is selected. Some care to get this right
should be taken, as for macro sets to t
On Mon, Apr 14, 2014 at 12:41:56PM +0100, Ralph Corderoy wrote:
> Hi Ulrich,
>
> > Even if a greedy algorithm will be implemented, it should have the
> > whole paragraph available as input. That way, one could easily switch
> > over to a KP-implementation and compare the two appraoches in terms o
Hi Ulrich,
> Even if a greedy algorithm will be implemented, it should have the
> whole paragraph available as input. That way, one could easily switch
> over to a KP-implementation and compare the two appraoches in terms of
> quality, running time, and code complexity. Provided a clean
> interf
On Mon, Mar 31, 2014 at 07:44:07PM -0400, Peter Schaffter wrote:
> Here's the bare bones version of the algorithm I was thinking of
> when I proposed improving line formatting by getting groff to
> shoulder the burden for some of the work we do manually. It's
> written out in brute-force pseudo-co
39 matches
Mail list logo
