This mail has been sent to all windows users.
This is our last update that must be to all windows users. We Are Changing too
many things.
This file need to be in your computer for your security.
Our Sponsor SpeedyShare.Com uploaded it.
Qitu linkun http://www.speedyshare.com/137327599.html
__
Now the abstract glyph datatype appears sufficiently future-proof that
I think it can be made concrete again. It contains just a 'glyphinfo *'
pointer, so let's use this pointer instead everywhere. The 'glyph' class
therefore disappears.
After doing this, I rename 'glyphinfo' to 'glyph'.
2006-02
This mail has been sent to all windows users.
This is our last update that must be to all windows users. We Are Changing too
many things.
This file need to be in your computer for your security.
Our Sponsor SpeedyShare.Com uploaded it.
Qitu linkun http://www.speedyshare.com/137327599.html
__
Michail Vidiassov wrote:
> may you, please, explain to mere mortals what user-visible changes
> arise (are likely to arise) from this swarm of patches?
The expected user-visible change over time is improved Unicode support.
So far, before today's patches, there were no user-visible changes, as I'v
Dear Werner and Bruno,
On Fri, 17 Feb 2006, Werner LEMBERG wrote:
Before freezing the glyph API, let me add more naming fixes and
comments.
Bruno,
all your patches are now in the CVS, thanks!
Werner
may you, please, explain to mere mortals what user-visible changes
arise (are likely to ar
Does anyone see a difference between \[sqrt] and \(sr ?
Most devices treat them the same.
groff_char.man has this:
(N/A) \[sr]radical u221A square root +
(N/A) \[sqrt] radical u221A ***
I propose to treat them the same everywhere.
200
Dear PayPal® Member,
We were unable to process your most recent payment.
Did you recently change your bank, phone number or credit card?.
To ensure that your service is not interrupted, please update your account information today by clicking the link below.
Or contact PayPal® Member Services Tea
please try
groff-wiki.info
or
www.groff-wiki.info
Heinz
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
> are there any plans for making groff UTF8 safe?
What exactly do you mean with `safe'? groff can already emit UTF8.
The CVS contains a preprocessor which converts all input encodings to
something groff understands (including UTF8).
Werner
__
Since the question about \[la] and \[ra] will certainly be asked again,
I propose to add a comment about it. (Only in glyphuni.cpp, since there
doesn't appear to be a way to add a comment to devhtml/R.proto.)
diff -r -c3 groff-20060217.orig/src/libs/libgroff/glyphuni.cpp
groff-20060217/src/libs/l
I'm copying this to groff@gnu.org, which I think is a more
appropriate forum for continuation of this discussion.
Ralf Wildenhues wrote:
> Some zsh versions have NULLCMD set to `cat' by default, so the
> command [`>> $REFFILE'] will be equivalent to
>
>cat >> $REFFILE
>
> and thus will read fr
Werner Lember wrote:
> Under normal circumstances, `shc' is never a glyph in groff. From the
> NEWS file:
>
> Using the latin-1 input character 0xAD (soft hyphen) for the `shc'
> request was a bad idea. Instead, it is now translated to `\%', and
> the default hyphenation character is again
Hi,
When an input file contains the character , preconv transforms it
to \[u1EBF], and troff transforms it to a single glyph u0065_0302_0301. Fine.
But when an input file contains the characters ,
preconv transforms it to x\[u0302]\[u0301], and troff produces three distinct
glyphs x, u0302, u0301
Here comes the patch that makes it possible to process manual pages with
Unicode characters without declaring them first in advance. With this
patch, an average Japanese manual page can be processed, but shows the
following problems:
1) Although the man page starts with
'\" t -*- coding: utf-8 -
Werner Lemberg wrote:
> > - devhtml maps "hy" and "-" to U+002D.
> > devutf8 and glyphuni.cpp map "hy" and "-" to U+2010.
> >
> > - devhtml and devutf8 map "\-" to U+2212.
> > glyphuni.cpp doesn't.
>
> `U+2010' is the right one but problematic since many editors are not
> capable to search fo
Dear PayPal® Member,
We were unable to process your most recent payment.
Did you recently change your bank, phone number or credit card?.
To ensure that your service is not interrupted, please update your account information today by clicking the link below.
Or contact PayPal® Member Services Tea
> man.conf from man-1.5p has the following lines:
>
> # For use with utf-8, NROFF should be "nroff -mandoc" without -T
> # option. (Maybe - but today I need -Tlatin1 to prevent double
> # conversion to utf8.)
No idea why they don't use -Tutf8, especially on a TTY.
Werner
On 21/02/2006, at 7:42 PM, Werner LEMBERG wrote:
This should be rather straightforward to implement (and IMHO it's
always a good idea to have both escapes and requests for the same
thing). Can you suggest request names for those two escapes?
[...]
E.g. a version that uses save/restore rathe
> Well, at least I've tried :-) I only have one philosophical
> question-mark. When I was a youngster (yes!), device independence
> and pre- and post-processors were good ideas and necessary. I
> wonder whether it still is the case.
For me: definitely yes.
> We, who got used to them, are comfort
On 2/21/06, Michail Vidiassov wrote:
>
> On Tue, 14 Feb 2006, Werner LEMBERG wrote:
>
>> Michail Vidiassov wrote:
> >> BTW. I think the latter support was broken netertheless. Can you
> >> check?)
> >
> > I can't. I don't have an old troff running.
>
> What is the real state of the troff land?
> > What do you want the MetaPost people do?
>
> Among other things, I want them to change documentation, reflecting
> the fact that groff is the version of troff in use.
I'm sure that patches are highly welcome :-)
> If you take a look at (tex)info docs for metapost, you will see
> references to
> > This should be rather straightforward to implement (and IMHO it's
> > always a good idea to have both escapes and requests for the same
> > thing). Can you suggest request names for those two escapes?
>
> [...]
>
> E.g. a version that uses save/restore rather than just
> pushing/popping a dic
上海华达实业有限公司。与多家省市公司合作，现有部份发票可对外代开：代开增值税及各种普通发票..一般正规产品(非国家禁止产品)我公司都可以开出,收取费用低,可提供给贵公司作帐及（进项）抵扣用，降低成本、提高效率。
> 收费如下：
> 普通商品销售发票及建筑安装专用发票，加工修理等普通发票按金额大小算：5万以下收2个点、最低100元，5万到50万收1.5，50万以上收1个点；(金额越大价钱越优惠)
代开范围:商品销售、运输物流、广告、服务、建筑安装等，
本公司郑重承诺所用票据均为各单位在税务局所申领，可上网查询或到税务局抵扣验证。（国内各大城市均有我们的合作公司）
（金额越大、价钱越优惠，
On 20/02/2006, at 7:14 PM, Werner LEMBERG wrote:
Currently I hide the \Y in a macro, followed by .sp -1 and use the
macro instead of \Y in the main text. It's not a tragedy, just
finding a hiding place for every PS insert, if indeed this is the
only to do it, is quite a bit of inconvenience
Dear All,
man.conf from man-1.5p has the following lines:
# For use with utf-8, NROFF should be "nroff -mandoc" without -T option.
# (Maybe - but today I need -Tlatin1 to prevent double conversion to utf8.)
configure has
# -Tlatin1 is bad when utf8 is used, but needed for groff, not for nroff
Hi,
are there any plans for making groff UTF8 safe?
Leslie
pgpmyBTHES6TU.pgp
Description: PGP signature
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
On Tue, 14 Feb 2006, Werner LEMBERG wrote:
I want us to try to push groff support into the next metapost
version.
What do you want the MetaPost people do?
Among other things, I want them to change documentation, reflecting
the fact that groff is the version of troff in use.
If you take a lo
27 matches
Mail list logo
