oal in filing the bug wasn't to get
groff to accept this (since obviously it was invalid), but more on the
principle that software shouldn't segfault even in the face of invalid
input.
--
brian m. carlson (he/him or they/them)
Houston, Texas, US
signature.asc
Description: PGP signature
> exact cause.
>
> $ groff -V -s -Kcp1251 -t -Tutf8
> soelim | preconv -ecp1251 | tbl | troff -Tutf8 | grotty
Not that you should ever do this, but if you were using, say, UTF-16,
soelim would not be very effective unless preconv ran first.
--
brian m. carlson / brian with sandals: Houston,
7;s my preferred macro
package, but of course everyone will have their own preferences.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
signature.asc
Description: Digital signature
ot likely to work. You should definitely try it first.
Maybe you can see if LibreOffice can import PDFs successfully; it can
output to Word format if you need to.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion onl
be considered "upstream".
There are two sets of the -me macros. One is the set that is still used
on BSD systems today. The other is the set that's part of groff that
was derived from an earlier BSD version and heavily modified. Which one
you use depends on which system you ha
looked at the "Writing
Macros" and "Strings" sections. Maybe you could say something like,
"Although these requests can be used to create macros and strings,
simply using an undefined macro will cause it to be defined as empty."
and then a reference to the "Identif
't mention that behavior. The Heirloom troff
documentation doesn't mention that behavior either. I do get the
expected result if I put an appropriate .rm statement after the .do.
I'm using Debian's groff 1.21-6. Is this the way things are supposed to
be?
--
brian m. carls
has to be
reflowable, and groff doesn't do that very well.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
signature.asc
Descripti
IP to 0, and you'll find that it prints "This is a test, SIP only."
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
signature.asc
Description: Digital signature
On Sat, Jul 03, 2010 at 02:11:13AM +0100, Deri James wrote:
> As all the commands after "brian m. carlson" are introduced with apostrophes
> no breaks occur until the final .br (at which time .ad b is in effect rather
> than the earlier .ad c).
>
> If you replace
.
It seems a little odd to me that a break *after* the text, but *before*
another change of adjustment is required to make this work. Is this
behavior intentional?
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion
n.
Debian includes a groff-base and a groff. The former is useful mostly
for formatting manpages, but the latter adds all the things that the
former is missing. In other words, the groff package should include a
complete groff environment.
--
brian m. carlson / brian with sandals: Houston
it, but if it's the former, it's never going to be fixed.
GCC 4.0.1 is pretty old.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
signature.asc
Description: Digital signature
use -sDEVICE=epswrite instead of -sDEVICE=pswrite.
That way, your output is guaranteed to be EPS. Alternatively, you could
use ps2epsi, which will produce a less grainy output.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My
idea; there's probably a different way to do it. The
code itself is left as an exercise.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
signature.asc
Description: Digital signature
or can be ignored) by
many non-Adobe viewers. Therefore, setting them is merely an
inconvenience that irritates your viewers, not an effective control
mechanism. I strongly recommend that you omit them.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothp
ly font output when viewing PostScript files in X, whereas poppler
produces nice output for PDF. I guess I'll go back to piping the output
of groff into ps2pdf.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
Op
pt.
Since I'm not sure how pdfroff is supposed to work, the best I can do is
describe the problem.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 22
ps2pdf - file.pdf
and it works just fine.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
signature.asc
Description: Digital signature
, which should be
> perfectly legal.
Actually, on Windows, that's "wb+".
I have a suspicion that using fdopen(3) with the "b" flag but not
opening fd using O_BINARY could be the cause of the problem; that would
need to be fixed in tmpname.cpp. Seeing as I don't ha
that were
shipped by default. You might check the archive to be sure.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b
the `' pair
in the source which will be mapped onto ‘’ in UTF-8 output, and to give
up on anything approaching decent output in ASCII.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http
request of the same name, with no way to get the original
one back. Don't do that.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
O
ect to send
patches or at least file bug reports.
I don't know if this is exactly what you are looking for, but it can
probably be manipulated into doing what you want.
HTH.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustyt
quot; at the bottom of the
page, exhibit this behavior.
What Heirloom troff does differently is that it probably melds these
into a K with combining diacritic, whereas groff almost certainly does
not.
HTH.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://
later. IMHO, they seem like different concepts, since one deals with
input and one deals more with the output side.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
a typesetting engine: http://crustytoothpaste.
r handling Unicode ranges:
CJKpunct u3000 - u303F;
My intention was that any valid glyph name was to be valid as a class
character, but name_to_glyph apparently doesn't handle Unicode
characters. Should I be using a different function, or should I extend
name_to_glyph?
--
b
oning if I am wrong.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
a typesetting engine: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B18
RE and BREAK_AFTER. If I clear the BREAK_BEFORE flag on a
glyph, will that prevent the line from being broken before that glyph
(and similarly the BREAK_AFTER flag)? If so, kinsoku shori handling
might be done by the end of the week.
--
brian m. carlson / brian with sandals: Houston, Texas,
busing the
hyphenation and filling code, but I could always implement glyph classes
instead. I'll probably implement the glyph classes, since that needs to
be done anyway, and it is the Right Way to do it.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 |
the standard FSF form if necessary, should I
produce usable work.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
a typesetting engine: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b
vious
reasons, cannot be printed and will cause a diagnostic message if you
attempt to do so.
For more information, see the "Strings" section of the groff info pages.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opi
and italic fonts are often used for at least the synopsis section (see
e.g. groff(1)).
I will admit that it is difficult to get people to use \- instead of -,
but there's really no alternative. I'm pretty sure that all other troff
implementations map \- to U+002D (mine does as of the
fo2troff.xsl;h=c6ef9b0002bd9e551ca339a0dd88d24618eb822f;hb=HEAD
[1] http://crustytoothpaste.ath.cx/~bmc/code/projects#thwack
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
&& make && sudo make
install" from there.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
35 matches
Mail list logo