paps-discuss — General discussions about paps

Re: [Paps-discuss] Is anyone still subscribed?

[Akira T. <ak...@ta...>]

Hi Dov,

That sounds good to me. I'm looking forward to seeing the updates on it.

Thanks,

On Sun, Dec 25, 2022 at 5:46 PM Dov Grobgeld <dov...@gm...> wrote:
>
> Hello,
>
> Is anyone still subscribed to this list? I'd like to close it and move to github discussions instead at:
>
> https://github.com/dov/paps/discussions
>
> Note that I have recently "revived" my attention to paps, and I would be happy to receive some feedback on my latest changes.
>
> Please let me know, who is still around.
>
> Regards,
> --
> @do...@fo...
>
> On Fri, Nov 3, 2006 at 5:14 PM Akira TAGOH <at...@gc...> wrote:
>>
>> >>>>> On Fri, 3 Nov 2006 12:11:47 +0200,
>> >>>>> "DG" == "Dov Grobgeld" <dov...@gm...> wrote:
>>
>> DG> On 11/3/06, Akira TAGOH <at...@gc...> wrote:
>> DG> Regarding CUPS, I'm not very familiar with how it works, but I am sure
>> DG> that you can create a script that works as the which then calls an
>> DG> unmodified version of paps. That might even be better as that may
>> DG> provide a standard way of changing defaults (by modifying the scripts
>> DG> default parameter's file.
>>
>> Maybe. but I'd prefer to patch it out so that a filter
>> programs may needs to call CUPS APIs for various reasons,
>> which means it might not be dealt on a shell script.
>>
>> >> However specifying a font and a font size may be still good
>> >> feature for paps since paps doesn't support the direct
>> >> printing or just works as a frontend filter program, because
>> >> it won't causes wasting their papers directly. they can just
>> >> try out before getting the real printing.  but CUPS filters
>> >> aren't supposed to do so since it has to be a backend filter
>> >> program.
>>
>> DG> Sorry. I didn't follow this. You can of course change the font size in
>> DG> the font_desc option. Is this what you meant?
>>
>> Well, no. erm, of course I could hardcode a font name and a
>> font size for default though, but noone can do it as an
>> option -- I meant it would be helpful as long as users uses
>> paps as paps, but not be helpful for paps as CUPS filter
>> because of the reason I wrote in previous mail.  For more
>> details, you just use lpr command for printing and CUPS
>> invokes the proper filter according to their MIME
>> types. which means all CUPS filters isn't basically desired
>> to be invoked directly and they has the same command line
>> interface for CUPS without any exceptions, including paps as
>> CUPS filter, which is included in Fedora Core.  To not get
>> confused, FC's paps behaves CUPS filter only when it's
>> invoked from CUPS or as "texttopaps". otherwise it just
>> works as an unmodified version of paps, but anyway.
>> So, what options are given to CUPS filters depends on
>> CUPS. there are no such options to change the font nor the
>> font size directly right now IIRC. then I don't think
>> CPI/LPI isn't really used. otherwise they didn't have such
>> features.
>>
>> >> Sounds nice. so does people need to give paps a Pango marked
>> >> up text, right? it would be nice if paps can highlight the
>> >> text automatically according to its format.
>>
>> DG> There are a few ways that can be done:
>>
>> DG> 1. Modify highlight to output pango markup and then invoke highlight
>> DG> as a subprocess under paps.
>>
>> DG> 2. Like 1 but let some new additional external program first call
>> DG> highlight and then paps.
>>
>> DG> 3. Let paps call highlight and have it generate XML output which is
>> DG> then parsed and turned into pango markup.
>>
>> DG> 4. Like 3 but let an external program tie it together.
>>
>> DG> In any case, there is no reason to reinvent the wheel of GNU
>> DG> highlight. I would probably start with option 4 and a perl program to
>> DG> tie things together.
>>
>> Ok, I see. I'd love it. it would be also nice to be
>> controllable a feature at configure as optional for those
>> who don't want or don't have GNU highlight.
>>
>> Cheers,
>> --
>> Akira TAGOH
>
> _______________________________________________
> Paps-discuss mailing list
> Pap...@li...
> https://lists.sourceforge.net/lists/listinfo/paps-discuss



-- 
Akira TAGOH

[Paps-discuss] Is anyone still subscribed?

[Dov G. <dov...@gm...>]

Hello,

Is anyone still subscribed to this list? I'd like to close it and move to
github discussions instead at:

https://github.com/dov/paps/discussions

Note that I have recently "revived" my attention to paps, and I would be
happy to receive some feedback on my latest changes.

Please let me know, who is still around.

Regards,
--
@do...@fo...

On Fri, Nov 3, 2006 at 5:14 PM Akira TAGOH <at...@gc...> wrote:

> >>>>> On Fri, 3 Nov 2006 12:11:47 +0200,
> >>>>> "DG" == "Dov Grobgeld" <dov...@gm...> wrote:
>
> DG> On 11/3/06, Akira TAGOH <at...@gc...> wrote:
> DG> Regarding CUPS, I'm not very familiar with how it works, but I am sure
> DG> that you can create a script that works as the which then calls an
> DG> unmodified version of paps. That might even be better as that may
> DG> provide a standard way of changing defaults (by modifying the scripts
> DG> default parameter's file.
>
> Maybe. but I'd prefer to patch it out so that a filter
> programs may needs to call CUPS APIs for various reasons,
> which means it might not be dealt on a shell script.
>
> >> However specifying a font and a font size may be still good
> >> feature for paps since paps doesn't support the direct
> >> printing or just works as a frontend filter program, because
> >> it won't causes wasting their papers directly. they can just
> >> try out before getting the real printing.  but CUPS filters
> >> aren't supposed to do so since it has to be a backend filter
> >> program.
>
> DG> Sorry. I didn't follow this. You can of course change the font size in
> DG> the font_desc option. Is this what you meant?
>
> Well, no. erm, of course I could hardcode a font name and a
> font size for default though, but noone can do it as an
> option -- I meant it would be helpful as long as users uses
> paps as paps, but not be helpful for paps as CUPS filter
> because of the reason I wrote in previous mail.  For more
> details, you just use lpr command for printing and CUPS
> invokes the proper filter according to their MIME
> types. which means all CUPS filters isn't basically desired
> to be invoked directly and they has the same command line
> interface for CUPS without any exceptions, including paps as
> CUPS filter, which is included in Fedora Core.  To not get
> confused, FC's paps behaves CUPS filter only when it's
> invoked from CUPS or as "texttopaps". otherwise it just
> works as an unmodified version of paps, but anyway.
> So, what options are given to CUPS filters depends on
> CUPS. there are no such options to change the font nor the
> font size directly right now IIRC. then I don't think
> CPI/LPI isn't really used. otherwise they didn't have such
> features.
>
> >> Sounds nice. so does people need to give paps a Pango marked
> >> up text, right? it would be nice if paps can highlight the
> >> text automatically according to its format.
>
> DG> There are a few ways that can be done:
>
> DG> 1. Modify highlight to output pango markup and then invoke highlight
> DG> as a subprocess under paps.
>
> DG> 2. Like 1 but let some new additional external program first call
> DG> highlight and then paps.
>
> DG> 3. Let paps call highlight and have it generate XML output which is
> DG> then parsed and turned into pango markup.
>
> DG> 4. Like 3 but let an external program tie it together.
>
> DG> In any case, there is no reason to reinvent the wheel of GNU
> DG> highlight. I would probably start with option 4 and a perl program to
> DG> tie things together.
>
> Ok, I see. I'd love it. it would be also nice to be
> controllable a feature at configure as optional for those
> who don't want or don't have GNU highlight.
>
> Cheers,
> --
> Akira TAGOH
>

[Paps-discuss] paps-discuss@lists.sourceforge.net is compromised. Password must be changed

[<pap...@li...>]

Hello!

I'm a programmer who cracked your email account and device about half year ago.
You entered a password on one of the insecure site you visited, and I catched it.

Of course you can will change your password, or already made it.
But it doesn't matter, my rat software update it every time.

Please don't try to contact me or find me, it is impossible, since I sent you an email from your email account.

Through your e-mail, I uploaded malicious code to your Operation System.
I saved all of your contacts with friends, colleagues, relatives and a complete history of visits to the Internet resources.
Also I installed a rat software on your device and long tome spying for you.

You are not my only victim, I usually lock devices and ask for a ransom.
But I was struck by the sites of intimate content that you very often visit.

I am in shock of your reach fantasies! Wow! I've never seen anything like this!
I did not even know that SUCH content could be so exciting!

So, when you had fun on intime sites (you know what I mean!)
I made screenshot with using my program from your camera of yours device.
After that, I jointed them to the content of the currently viewed site.

Will be funny when I send these photos to your contacts! And if your relatives see it?
BUT I'm sure you don't want it. I definitely would not want to ...

I will not do this if you pay me a little amount.
I think $897 is a nice price for it!

I accept only Bitcoins.
My BTC wallet: 1M2D1PzyyiZBrSh8qcdts5kecQAX3S9xuF

If you have difficulty with this - Ask Google "how to make a payment on a bitcoin wallet". It's easy.
After receiving the above amount, all your data will be immediately removed automatically.
My virus will also will be destroy itself from your operating system.

My Trojan have auto alert, after this email is looked, I will be know it!

You have 2 days (48 hours) for make a payment.
If this does not happen - all your contacts will get crazy shots with your dirty life!
And so that you do not obstruct me, your device will be locked (also after 48 hours)

Do not take this frivolously! This is the last warning!
Various security services or antiviruses won't help you for sure (I have already collected all your data).

Here are the recommendations of a professional:
Antiviruses do not help against modern malicious code. Just do not enter your passwords on unsafe sites!

I hope you will be prudent.
Bye.

Re: [Paps-discuss] Fwd: cairo based paps

[Akira T. <ak...@ta...>]

Hi,

Yes, I am. I was trying to port the feature to cairo-based paps but stalled
at this moment because most of it depended on PostScript and is currently
out of  control through cairo. so need to patch out in cairo to keep things
working. due to that, I'm not yet updating the package in Fedora, but
anyway.

You may better drop that feature so far perhaps.

On Mon, Nov 16, 2015 at 6:13 PM, Dov Grobgeld <dov...@gm...>
wrote:

> Akira, are you still on the list? Would you mind checking out issue #16?
>
>
> ---------- Forwarded message ----------
> From: Jan Hnatek <jan...@or...>
> Date: Mon, Nov 16, 2015 at 11:07 AM
> Subject: Re: [Paps-discuss] cairo based paps
> To: Dov Grobgeld <dov...@gm...>
>
>
> Hi Dov,
>
> I would like to plan the integration of paps to Solaris and so I'd like
> to check with you about the latest status.
>
> Do you perhaps have any feedback from Akira re. the latest changes?
> How do you think about the page header layout?
>
> I was wondering if you could let me know what the plans are, as it'd
> be much better to take a release version for the integration.
>
> Thanks & regards,
> Jan
>
>
> On 10/21/2015 09:22 AM, Dov Grobgeld wrote:
>
>> Hi Jan,
>>
>> All of the cpi and lpi the stretchable characters were contributed by
>> Akira Togoh of Redhat, and I never got into the depth of what it does. I
>> guess it is some compatibility issue with some previous technology. I
>> guess I should just reassign the bug to him.
>>
>> Regards,
>> Dov
>>
>>
>> On Wed, Oct 21, 2015 at 9:15 AM, Jan Hnatek <jan...@or...
>> <mailto:jan...@or...>> wrote:
>>
>>     Hi Dov,
>>
>>     thanks for fixing the default markup font.
>>
>>     Regarding the issue #16 (--stretch-chars) I filed it as I was testing
>>     all of the options and couldn't make this work, but it's not a high
>>     priority in my opinion. I wonder if it's still useful to anyone.
>>
>>     Regards,
>>     hnhn
>>
>>
>>
>>     --
>>     jan...@or... <mailto:jan...@or...>
>>
>>       🍺
>>
>>
>>
> --
> jan...@or...
>
>  🍺
>
>
>
>
> ------------------------------------------------------------------------------
> Presto, an open source distributed SQL query engine for big data, initially
> developed by Facebook, enables you to easily query your data on Hadoop in a
> more interactive manner. Teradata is also now providing full enterprise
> support for Presto. Download a free open source copy now.
> http://pubads.g.doubleclick.net/gampad/clk?id=250295911&iu=/4140
> _______________________________________________
> Paps-discuss mailing list
> Pap...@li...
> https://lists.sourceforge.net/lists/listinfo/paps-discuss
>
>


-- 
Akira TAGOH

[Paps-discuss] Fwd: cairo based paps

[Dov G. <dov...@gm...>]

Akira, are you still on the list? Would you mind checking out issue #16?


---------- Forwarded message ----------
From: Jan Hnatek <jan...@or...>
Date: Mon, Nov 16, 2015 at 11:07 AM
Subject: Re: [Paps-discuss] cairo based paps
To: Dov Grobgeld <dov...@gm...>


Hi Dov,

I would like to plan the integration of paps to Solaris and so I'd like
to check with you about the latest status.

Do you perhaps have any feedback from Akira re. the latest changes?
How do you think about the page header layout?

I was wondering if you could let me know what the plans are, as it'd
be much better to take a release version for the integration.

Thanks & regards,
Jan


On 10/21/2015 09:22 AM, Dov Grobgeld wrote:

> Hi Jan,
>
> All of the cpi and lpi the stretchable characters were contributed by
> Akira Togoh of Redhat, and I never got into the depth of what it does. I
> guess it is some compatibility issue with some previous technology. I
> guess I should just reassign the bug to him.
>
> Regards,
> Dov
>
>
> On Wed, Oct 21, 2015 at 9:15 AM, Jan Hnatek <jan...@or...
> <mailto:jan...@or...>> wrote:
>
>     Hi Dov,
>
>     thanks for fixing the default markup font.
>
>     Regarding the issue #16 (--stretch-chars) I filed it as I was testing
>     all of the options and couldn't make this work, but it's not a high
>     priority in my opinion. I wonder if it's still useful to anyone.
>
>     Regards,
>     hnhn
>
>
>
>     --
>     jan...@or... <mailto:jan...@or...>
>
>       🍺
>
>
>
-- 
jan...@or...

 🍺

[Paps-discuss] cairo based paps

[Dov G. <dov...@gm...>]

Hi All,

I have finally created an initial cairo based version of paps.

The version is available at http://github.com/dov/paps branch cairo.

I would very much appreciate if you can test it out and let me know of any
problems.

Regards,
Dov

[Paps-discuss] fontname problems

[Jan W. S. <jws...@gm...>]

Hi, long time no see.

I found 2 problems with font names in paps:

1) the font name itself must one word, i.e. without spaces. E.g. from 
the terminal prompt:
--font="Impact 32"
paps --font="Impact 32"
Failed to open 32"!

    paps --font="Arial 32" test.txt >output.ps

works as expected, but

    paps --font="Times New Roman 32" test.txt >output.ps

does not.

2) The situation is even worse when paps is called from a shell script 
and the arguments to paps are in a string. Then we cannot even make 
"Arial 32" work.

Shell script:

    #!/bin/sh
    FONT="--font=\"Arial 32\""
    echo $FONT
    paps $FONT test.txt >output.ps

Of which the output (on the console) is:

    --font="Arial 32"
    Failed to open 32"!

3) So directly on the command line we cannot specify font names with 
spaces. In a shell script, also the font size cannot be specified. My 
problem is that I want to use paps as a replacement for a2ps in a 
Brother laser printer driver, which is a shell script. So far no luck, 
despite experimenting with innumerable quoting styles trying to preserve 
the spaces.

Any help would be appreciated.

Regards, Jan

Re: [Paps-discuss] printing librarian data with paps 0.6.8

[Matthias A. <gu...@un...>]

El día Wednesday, September 21, 2011 a las 04:36:00PM +0300, Dov Grobgeld escribió:

> I realized that I must have misunderstood you. I misread OCR font as a
> Barcode font (yes, my mistake) and thought that it must have some strange
> encoding. But since it appears that it is a standard font and you have
> copied it to the standard plaace, you may much easier use it through:
> 
> <span font="OCR-B 12">ABC 123</span>

Thanks, this works as it should.

Now, because you say "Barcode font", and since I see how pango+cairo can
paint something to Postscript, another project waiting for a good
solution comes into my mind... Are there any Barcode fonts that I should
integrate (by placing them into the ~/.fonts dir) and I could use 
from cairo?

Thanks for a pointer

	matthias
-- 
Matthias Apitz
t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
e <gu...@un...> - w http://www.unixarea.de/

Re: [Paps-discuss] printing librarian data with paps 0.6.8

[Dov G. <dov...@gm...>]

I realized that I must have misunderstood you. I misread OCR font as a
Barcode font (yes, my mistake) and thought that it must have some strange
encoding. But since it appears that it is a standard font and you have
copied it to the standard plaace, you may much easier use it through:

<span font="OCR-B 12">ABC 123</span>

Use fc-list to get the font-config name of the font, which is used by cairo
as well.

Regarding the baseline position of text through pango, you should look at
the following example:

http://live.gnome.org/PangoLayoutLineBbox

But again, by using ORC-B from within Pango, I don't think that you need it.

Regards,
Dov

On Wed, Sep 21, 2011 at 16:24, Matthias Apitz <gu...@un...> wrote:

> El día Monday, September 19, 2011 a las 01:31:24PM +0200, Matthias Apitz
> escribió:
>
> > > OCR-B font? Depending on your encoding
> > > you may find it sufficient and easier to use the cairo text interface
> > > instead:
> > >
> > > http://cairographics.org/manual/cairo-text.html
> >
> > Thanks for the pointer concerning OCR-B.
>
> Hello Dov,
>
> I have expanded my small test pgm postscript.c to use the font OCRB.pfb
> (which is in ~/.fonts/ dir) from Cairo; see the function renderocrb();
> and the PostScript output is attached as well;
>
> one (maybe last) question: it would be good if I could put the two
> different
> fonts, i.e. the "normal" font for the CJK/UTF-8 text and the OCR-B
> string, on the same line; but as far as I understand how
> pango_layout_set_markup() works, this is not possible;
>
> any idea how to solve this?
>
> Thanks
>
>        matthias
> --
> Matthias Apitz
> t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
> e <gu...@un...> - w http://www.unixarea.de/
>

Re: [Paps-discuss] printing librarian data with paps 0.6.8

[Matthias A. <gu...@un...>]

El día Monday, September 19, 2011 a las 03:31:47PM +0300, Dov Grobgeld escribió:

> Regarding g_object_unref(), my mistake. I guess my fingers were too trigger
> happy. Great that it works.
> 
> Good luck!
> Dov
> 

I need another small hint now, concerning Postscript; my code works a
bit, but only print Prolog etc., no real page. Perhaps I do again
something stupid wrong with what I have found in the manuals. Thanks in
advance

	matthias
-- 
Matthias Apitz
t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
e <gu...@un...> - w http://www.unixarea.de/

Re: [Paps-discuss] printing librarian data with paps 0.6.8

[Dov G. <dov...@gm...>]

Regarding g_object_unref(), my mistake. I guess my fingers were too trigger
happy. Great that it works.

Good luck!
Dov

On Mon, Sep 19, 2011 at 15:23, Matthias Apitz <gu...@un...> wrote:

> El día Monday, September 19, 2011 a las 02:50:29PM +0300, Dov Grobgeld
> escribió:
>
> > Hi Matthias,
> >
> > You are making two mistakes:
> >
> >
> >    1. You don't call cairo_move_to() before drawing the text. This causes
> >    cairo to move its point to the first position after the bounding box
> of the
> >    strign.
> >    2. You use cairo_translate() without using surrounding cairo_save()
> and
> >    cairo_restore() to preserve the global translation matrix.
>
> Hi Dov,
>
> I did the mistake because I started from a tutorial sample code in
> http://x11.gp2x.de/personal/google/
> the example1.c there used cairo_translate() only and without
> cairo_save() and cairo_restore();
>
> thanks for the tip; with your code it works now as I expect; one
> question: your code does not have anymore
>
>        g_object_unref(layout);
>
> at the end of rendertext(), why?
>
> I will move over to next step: Postscript;
> Thanks
>
>        matthias
> --
> Matthias Apitz
> t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
> e <gu...@un...> - w http://www.unixarea.de/
>

Re: [Paps-discuss] printing librarian data with paps 0.6.8

[Matthias A. <gu...@un...>]

El día Monday, September 19, 2011 a las 02:50:29PM +0300, Dov Grobgeld escribió:

> Hi Matthias,
> 
> You are making two mistakes:
> 
> 
>    1. You don't call cairo_move_to() before drawing the text. This causes
>    cairo to move its point to the first position after the bounding box of the
>    strign.
>    2. You use cairo_translate() without using surrounding cairo_save() and
>    cairo_restore() to preserve the global translation matrix.

Hi Dov,

I did the mistake because I started from a tutorial sample code in
http://x11.gp2x.de/personal/google/
the example1.c there used cairo_translate() only and without
cairo_save() and cairo_restore(); 

thanks for the tip; with your code it works now as I expect; one
question: your code does not have anymore 

	g_object_unref(layout);

at the end of rendertext(), why?

I will move over to next step: Postscript;
Thanks

	matthias
-- 
Matthias Apitz
t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
e <gu...@un...> - w http://www.unixarea.de/

Re: [Paps-discuss] printing librarian data with paps 0.6.8

[Dov G. <dov...@gm...>]

Hi Matthias,

You are making two mistakes:


   1. You don't call cairo_move_to() before drawing the text. This causes
   cairo to move its point to the first position after the bounding box of the
   strign.
   2. You use cairo_translate() without using surrounding cairo_save() and
   cairo_restore() to preserve the global translation matrix.

To fix this you can change your code to:

 void rendertext(cairo_t *cr, char *text, float line) {

  PangoLayout *layout;

  PangoFontDescription *desc;

  layout = pango_cairo_create_layout(cr);

  pango_layout_set_markup(layout, text, -1);

  desc = pango_font_description_from_string("Monospace 16");

  pango_layout_set_font_description(layout, desc);

  pango_font_description_free(desc);

  cairo_set_source_rgb(cr, 0.0, 0.0, 1.0);

  pango_cairo_update_layout(cr, layout);

  cairo_move_to(cr, 0,line);

  pango_cairo_show_layout(cr, layout);

}


Regards,
Dov



On Mon, Sep 19, 2011 at 14:31, Matthias Apitz <gu...@un...> wrote:

>
> Hello Dov,
>
> Thanks for your helping hand;
>
> El día Monday, September 19, 2011 a las 10:56:55AM +0300, Dov Grobgeld
> escribió:
>
> > I'm afraid that I know of no such tutorial, but for what you want to
> achieve
> > I think that the link that I sent you should be sufficient. Basically you
> > want to create a pango layout in whatever font and size, and then paste
> it
> > in your cairo surface. Why isn't your small-hello.utf8 example enough for
> > you?
>
> I have put together all I have learned from places I found w/ Google and
> I am now able to render some text, even with markup; but the positioning
> with cairo_translate() does not work as I expect (see the attachment of
> example1.c and its output out.png); I'm trying to print lines of UTF-8
> text (because this is mostly what I need for this printing). The text
> and bold/italic comes out fine, but with some stairs-effect. Not only
> stairs, but as well the distance between the lines is growing. Any idea
> what I do wrong?
>
> > What are you missing? Postscript output? Create a cairo postscript
> > surface instead of an image surface.
>
> Yes, I saw this in some tutorial and will use this later, once I can
> solve the above problem.
>
> > OCR-B font? Depending on your encoding
> > you may find it sufficient and easier to use the cairo text interface
> > instead:
> >
> > http://cairographics.org/manual/cairo-text.html
>
> Thanks for the pointer concerning OCR-B.
>
> > Feel free to ask if you have more questions.
>
> Thanks
>
>        matthias
>
> --
> Matthias Apitz
> t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
> e <gu...@un...> - w http://www.unixarea.de/
>

Re: [Paps-discuss] printing librarian data with paps 0.6.8

[Dov G. <dov...@gm...>]

I'm afraid that I know of no such tutorial, but for what you want to achieve
I think that the link that I sent you should be sufficient. Basically you
want to create a pango layout in whatever font and size, and then paste it
in your cairo surface. Why isn't your small-hello.utf8 example enough for
you? What are you missing? Postscript output? Create a cairo postscript
surface instead of an image surface. OCR-B font? Depending on your encoding
you may find it sufficient and easier to use the cairo text interface
instead:

http://cairographics.org/manual/cairo-text.html

Feel free to ask if you have more questions.

Regards,
Dov

On Sun, Sep 18, 2011 at 17:47, Matthias Apitz <gu...@un...> wrote:

> El día Friday, September 16, 2011 a las 10:13:52AM +0300, Dov Grobgeld
> escribió:
>
> > Hi Matthias,
> >
> > Paps was indeed written some time ago, and since it was written the
> graphics
> > library cairo has integrated with pango and had it been written today it
> > would have been written that way. A rewrite of paps using cairo is really
> > overdue.
> >
> > For your solution I certainly suggest using cairo + pango in whatever
> > language these have bindings for. A solution similar to your problem can
> be
> > seen in the following example on the vala tutorial page:
> >
> > http://live.gnome.org/Vala/PangoCairoSample
> >
> > That example outputs png files, but you can easily change it to
> outputting
> > postscript.
> > ....
>
> Hi Dov,
>
> First of all, thanks for your reply.
>
> Do you have some pointer to a tutorial "Pango for C" for me?
> I found the cairo documentation, its FAQ and samples which are quite
> enough to start with. But for pango I only see the Pango Reference
> Manual.
>
> Using the FAQ of cairo I am already able to write your text of the file
> small-hello.utf8 to a png file, but this is certainly not enough, and
> the Pange Reference does not give much explanations :-(
>
> Thanks in advance
>
>        matthias
> --
> Matthias Apitz
> t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
> e <gu...@un...> - w http://www.unixarea.de/
>

Re: [Paps-discuss] printing librarian data with paps 0.6.8

[Matthias A. <gu...@un...>]

El día Friday, September 16, 2011 a las 10:13:52AM +0300, Dov Grobgeld escribió:

> Hi Matthias,
> 
> Paps was indeed written some time ago, and since it was written the graphics
> library cairo has integrated with pango and had it been written today it
> would have been written that way. A rewrite of paps using cairo is really
> overdue.
> 
> For your solution I certainly suggest using cairo + pango in whatever
> language these have bindings for. A solution similar to your problem can be
> seen in the following example on the vala tutorial page:
> 
> http://live.gnome.org/Vala/PangoCairoSample
> 
> That example outputs png files, but you can easily change it to outputting
> postscript.
> ....

Hi Dov,

First of all, thanks for your reply.

Do you have some pointer to a tutorial "Pango for C" for me?
I found the cairo documentation, its FAQ and samples which are quite
enough to start with. But for pango I only see the Pango Reference
Manual. 

Using the FAQ of cairo I am already able to write your text of the file
small-hello.utf8 to a png file, but this is certainly not enough, and
the Pange Reference does not give much explanations :-(

Thanks in advance

	matthias
-- 
Matthias Apitz
t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
e <gu...@un...> - w http://www.unixarea.de/

Re: [Paps-discuss] printing librarian data with paps 0.6.8

[Dov G. <dov...@gm...>]

Hi Matthias,

Paps was indeed written some time ago, and since it was written the graphics
library cairo has integrated with pango and had it been written today it
would have been written that way. A rewrite of paps using cairo is really
overdue.

For your solution I certainly suggest using cairo + pango in whatever
language these have bindings for. A solution similar to your problem can be
seen in the following example on the vala tutorial page:

http://live.gnome.org/Vala/PangoCairoSample

That example outputs png files, but you can easily change it to outputting
postscript.

You did not state what graphics you want to output, but with cairo you can
easily layout whatever graphics objects you want on the page, including text
by pango and if for some reason (encoding?) pango doesn't support the OCR-B
font, then you can use the simple cairo text interface to output the
necessary glyphs.

So in summary:


   1. Yes
   2. Since paps only supports a single font (in contrast to pags which uses
   pango markup) you would have to do weird things like defining virtual
   fontconfig files to include your OCR font. Absolutely not worth it, imo.
   3. Yes, together with cairo and pangocairo.

Regards,
Dov

On Thu, Sep 15, 2011 at 15:23, Matthias Apitz <gu...@un...> wrote:

>
> Hello,
>
> The background of my interest in paps (or pango) is that I'm working for
> a provider of IT solutions for libraries (catalogue, circulation and so,
> all IT stuff a library of a university needs, to not go into further
> marketing :-)). We moved with our recent version from ISO 8859-1 data to
> UTF-8 and all data of the library about users, books, ... is now stored
> in the database in UTF-8, including CJK data.
> The system is UNIX based and has of course printouts for
> orders, letters, etc., and in all the languages in which are data is
> stored in the database. This as background only.
>
> My questions:
>
> 1. It seems that paps is not developed further, the last modifications
> in the sources are from 2006; is this true?
>
> 2. We need to combine the rendering of UTF-8 to Postscript (as possible
> with paps) together with printing some chars in OCR-B font; at the moment
> we are doing this without paps, by embedding FreeFonts and OCR-B font and
> writing the Postscript with some Perl engine. The problem with this is
> that FreeFoont have no CJK support. Is there some way to
> handle OCR-B font with paps as well?
>
> 3. And last question: should we skip paps and use pango directly?
>
> Thanks for your time reading all this
>
> Regards
>
>        matthias
> --
> Matthias Apitz
> t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
> e <gu...@un...> - w http://www.unixarea.de/
>
>
> ------------------------------------------------------------------------------
> Doing More with Less: The Next Generation Virtual Desktop
> What are the key obstacles that have prevented many mid-market businesses
> from deploying virtual desktops?   How do next-generation virtual desktops
> provide companies an easier-to-deploy, easier-to-manage and more affordable
> virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
> _______________________________________________
> Paps-discuss mailing list
> Pap...@li...
> https://lists.sourceforge.net/lists/listinfo/paps-discuss
>

[Paps-discuss] printing librarian data with paps 0.6.8

[Matthias A. <gu...@un...>]

Hello,

The background of my interest in paps (or pango) is that I'm working for
a provider of IT solutions for libraries (catalogue, circulation and so,
all IT stuff a library of a university needs, to not go into further
marketing :-)). We moved with our recent version from ISO 8859-1 data to
UTF-8 and all data of the library about users, books, ... is now stored
in the database in UTF-8, including CJK data.
The system is UNIX based and has of course printouts for
orders, letters, etc., and in all the languages in which are data is
stored in the database. This as background only.

My questions:

1. It seems that paps is not developed further, the last modifications
in the sources are from 2006; is this true?

2. We need to combine the rendering of UTF-8 to Postscript (as possible
with paps) together with printing some chars in OCR-B font; at the moment
we are doing this without paps, by embedding FreeFonts and OCR-B font and
writing the Postscript with some Perl engine. The problem with this is
that FreeFoont have no CJK support. Is there some way to
handle OCR-B font with paps as well?

3. And last question: should we skip paps and use pango directly?

Thanks for your time reading all this

Regards

	matthias
-- 
Matthias Apitz
t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
e <gu...@un...> - w http://www.unixarea.de/

Re: [Paps-discuss] [Fwd: Re: typefaces print heavier with paps]

[Dov G. <dov...@gm...>]

Based on how paps works I really doubt that it has the anything to do with
pango. The current (pre-cairo version) uses pango to layout the text and get
the proper font and glyph positions. It then uses freetype2 directly to
extract the font outlines, which it converts to postscript.

Regarding OO, as far as I know it doesn't use pango.

Regards,
Dov

2008/5/16 Jan Willem Stumpel <jst...@pl...>:

>
>
> -------- Original Message --------
> Subject: Re: [Paps-discuss] typefaces print heavier with paps
> Date: Wed, 14 May 2008 16:59:54 +0200
> From: Jan Willem Stumpel <jws@my.home>
> To: john-thomas richards <jtr...@co...>
> References: <482...@co...>
> <4829E05A.5090902@my.home> <482...@co...>
>
> john-thomas richards wrote:
>
> > If I print with FreeMono 12 in OO.o and if I print with paps
> > using FreeMono 12, the paps output will be heavier.  It is the
> > same with other typefaces (e.g., Times New Roman in OO.o and
> > via paps), also.
>
> There seems to be someting wrong both with paps and with oo. On
> http://bugs.debian.org there is bug 348385, which says that the
> "extra bolding" occurs with some fonts in oo (it does not mention
> paps). This seems to be the reverse of your problem.
>
> There are also problems with rendering accented letters in oo.
> E.g. many fonts (not all) display (and print) é (e with sharp
> accent) as È (E with grave accent). This does not occur in paps
> and abiword.
>
> A very undesirable situation. I suspect that some library (pango
> perhaps?) used by oo and paps has developed bugs, or has changed
> the calling sequence of some of its functions.
>
> Regards, Jan
>
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Paps-discuss mailing list
> Pap...@li...
> https://lists.sourceforge.net/lists/listinfo/paps-discuss
>

[Paps-discuss] [Fwd: Re: typefaces print heavier with paps]

[Jan W. S. <jst...@pl...>]

-------- Original Message --------
Subject: Re: [Paps-discuss] typefaces print heavier with paps
Date: Wed, 14 May 2008 16:59:54 +0200
From: Jan Willem Stumpel <jws@my.home>
To: john-thomas richards <jtr...@co...>
References: <482...@co...>
<4829E05A.5090902@my.home> <482...@co...>

john-thomas richards wrote:

> If I print with FreeMono 12 in OO.o and if I print with paps
> using FreeMono 12, the paps output will be heavier.  It is the
> same with other typefaces (e.g., Times New Roman in OO.o and
> via paps), also.

There seems to be someting wrong both with paps and with oo. On
http://bugs.debian.org there is bug 348385, which says that the
"extra bolding" occurs with some fonts in oo (it does not mention
paps). This seems to be the reverse of your problem.

There are also problems with rendering accented letters in oo.
E.g. many fonts (not all) display (and print) é (e with sharp
accent) as È (E with grave accent). This does not occur in paps
and abiword.

A very undesirable situation. I suspect that some library (pango
perhaps?) used by oo and paps has developed bugs, or has changed
the calling sequence of some of its functions.

Regards, Jan

Re: [Paps-discuss] typefaces print heavier with paps

[Dov G. <dov...@gm...>]

Hi John,

I've seen the same problem and I'm quite clueless of where it comes from. On
the PostScript level all I am doing is to create a path of the outline of
the characters which I am then filling with the normal postscript fill
command. I have searched for ghostscript commands to see if there is any
parameter for blackness, but I still haven't found it...

In any case, paps really should be converted to using cairo as its backend
instead of postscript directly. And if the same problem then remains, then
it is a cairo problem, and not my problem anymore. I started the conversion
quite a while ago, but I have yet to finish it. One of these days...

Sorry I couldn't be of more help.

Dov


2008/5/13 john-thomas richards <jtr...@co...>:

> I am using paps 0.6.8 in Debian Lenny.  When I print a paps-converted file
> (plain text, from vim), the typeface is heavier than printing from, say,
> OpenOffice.org.  If I convert a file with 'paps --font "FreeMono 12" test >
> test.ps' and then print it, the characters are much thicker than from a
> GUI app or even from a2ps or enscript.  The text is not quite bold, but
> appears much heavier than it should.  It is more like the printer is using
> too much ink but I am only getting this from paps.  Any idea what could be
> causing this?  Is there a workaround?  I have googled for additional CLI
> options.  The paps website options do not match the options in Debian's man
> page but none of them seems to be the answer for this problem.
> --
> john-thomas
>

[Paps-discuss] typefaces print heavier with paps

[john-thomas r. <jtr...@co...>]

I am using paps 0.6.8 in Debian Lenny.  When I print a paps-converted 
file (plain text, from vim), the typeface is heavier than printing from, 
say, OpenOffice.org.  If I convert a file with 'paps --font "FreeMono 
12" test > test.ps' and then print it, the characters are much thicker 
than from a GUI app or even from a2ps or enscript.  The text is not 
quite bold, but appears much heavier than it should.  It is more like 
the printer is using too much ink but I am only getting this from paps. 
  Any idea what could be causing this?  Is there a workaround?  I have 
googled for additional CLI options.  The paps website options do not 
match the options in Debian's man page but none of them seems to be the 
answer for this problem.
--
john-thomas

Re: [Paps-discuss] (no subject)

[Dov G. <dov...@gm...>]

QW5vdGhlciBzaW1pbGFyIHNvbHV0aW9uIHRoYXQgSSBzdGFydGVkIHdvcmtpbmcgb24gZm9yIEhl
YnJldyBmb250cyBpcwp0byBhcHBseSBzdWNoIGhldXJpc3RpY3MgYnV0IHRoZW4gc2F2ZSB0aGUg
cmVzdWx0IGluIHRoZSByZWxldmFudApvcGVudHlwZSB0YWJsZXMuCgpOb3RlIHRoYXQgUGFuZ28g
ZG9lcyBzdXBwb3J0IHRoZSBpbXBsZW1lbnRhdGlvbiBvZiBzdWNoIGhldXJpc3RpY3MgaW4KdGhl
IHZhcmlvdXMgbW9kdWxlcy4gSSB3cm90ZSBzdWNoIGEgbW9kdWxlIGZvciBIZWJyZXcgd2hpY2gg
aXMgdXNlZCBpbgp0aGUgYWJzZW5zZSBvZiB0aGUgT3BlblR5cGUgdGFibGVzLgoKUmVnYXJkcywK
RG92CgpPbiAxMi8xMi8wNiwgVGhvbWFzIFdvbGZmIDx0b3dvQHRvd28ubmV0PiB3cm90ZToKPiBB
cm5lIEfDtnRqZSAo6auY55ub6I+vKSB3cm90ZToKPiA+IFRoZSBmb250cyBuZWVkIHRvIGNvbnRh
aW4gYSkgdGhlIGJhc2UgZ2x5cGhzIGIpIHRoZSBjb21iaW5pbmcKPiA+IGFjY2VudHMgYykgImFu
Y2hvcnMiIGluIHRoZSBHUE9TIHRhYmxlIHRvIHRlbGwgdGhlIHJlbmRlcmluZwo+ID4gZW5naW5l
IHdoZXJlIGV4YWN0bHkgdG8gcGxhY2UgdGhlIGFjY2VudHMuIEluIGZvbnRmb3JnZSB0aGlzIGlz
Cj4gPiBkb25lIGVhc2lseS4gOikKPgo+IEphbiBXaWxsZW0gU3R1bXBlbCB3cm90ZToKPiA+IC4u
Lgo+ID4gU28gdGhlIGFkdmljZSB0byB1c2VycyBoYXMgdG8gcmVtYWluOiB1c2UgcHJlLWNvbWJp
bmVkIGFjY2VudHMKPiA+IHdoZW5ldmVyIHBvc3NpYmxlLiBEb24ndCBjb3VudCBvbiB0aGUgImNv
bWJpbmluZyBhY2NlbnRzIgo+ID4gbWVjaGFuaXNtIHRvIHdvcmsuIEl0IHdvbid0LCBleGNlcHQg
ZnJvbSBzb21lIGx1Y2t5IGNhc2VzLgo+Cj4gQXJuZSBHw7Z0amUgKOmrmOebm+iPrykgd3JvdGU6
Cj4gPiB5ZXMsIGl0IGRlcGVuZHMgdG90YWxseSBvbiB0aGUgZm9udCB0byBkZWZpbmUgdGhlICpw
b3NpdGlvbiogb2YgdGhlCj4gPiBhY2NlbnRzIChhbmQgd2VhdGhlciBvciBub3QgdGhleSBjYW4g
YmUgc3RhY2tlZCkuIEJ1dCBpdCBkZXBlbmRzIG9uIHRoZQo+ID4gcmVuZGVyaW5nIGVuZ2luZSB0
byAqaW50ZXJwcmV0KiB0aGUgaW5mb3JtYXRpb24gdGhlIGZvbnQgZ2l2ZXMgYWJvdXQgdGhlCj4g
PiBhY2NlbnRzLgo+ID4KPiA+IEJUVzogdGhlcmUgd2FzIG5vIGlyb255IGluIG15IHN0YXRlbWVu
dC4gSW4gRm9udGZvcmdlIGl0IGlzIHJlYWxseSBlYXN5Cj4gPiB0byBkZWZpbmUgdGhlICJhbmNo
b3JzIi4gRm9yIGFsbCBwcmUtY29tcG9zZWQgTGF0aW4gYmFzZWQgY29tYmluYXRpb25zLAo+ID4g
eW91IGNhbiBnZXQgaXQgZG9uZSB3aXRoIGFyb3VuZCAxMCBhbmNob3IgY2xhc3NlcywgaW5jbHVk
aW5nIHRoZSBzdGFja2VkCj4gPiBvbmVzIGZvciBWaWV0bmFtZXNlLgo+ID4KPiA+IFRoZSBkaWZm
aWN1bHR5IGlzIHRvIGRlY2lkZSBob3cgdGhlIGNvbWJpbmF0aW9ucyBzaG91bGQgYmUgZGlzcGxh
eWVkLAo+ID4gaS5lLiB3aGljaCAic3RhbmRhcmQiIHRvIGZvbGxvdyBhbmQgd2hpY2ggc2NyaXB0
cyB0byBzdXBwb3J0Lgo+ID4gWW91IG5lZWQgdG8gZGVmaW5lIHRoZSBhbmNob3IgcG9pbnRzLCBi
b3RoIGZvciB0aGUgYmFzZSBnbHlwaHMgYW5kIHRoZQo+ID4gY29tYmluaW5nIGFjY2VudHMsIHNl
cGFyYXRlbHkgYW5kIGZvciBlYWNoIHBvc3NpYmxlIGNvbWJpbmF0aW9uLiBUaGlzIGlzCj4gPiBx
dWl0ZSBzb21lIHdvcmsuLi4KPgo+IFJpY2ggRmVsa2VyIHdyb3RlOgo+ID4gV2VsbCB0aGVyZSBh
cmUgdHdvIGZsaXAgc2lkZXMgdG8gdGhpcyBzaXR1YXRpb24uIE9uIHRoZSBvbmUgaGFuZAo+ID4g
eW91J3JlIHJpZ2h0LCBidXQgb24gdGhlIG90aGVyIGhhbmQgaWYgbm8gb25lIHRyaWVzIHRvIHVz
ZSB0aGUKPiA+IGNvbWJpbmluZyBjaGFyYWN0ZXJzLCBhcHBsaWNhdGlvbnMgYW5kIGZvbnRzIHdp
bGwgcmVtYWluIGJyb2tlbi4gOigKPiA+IFNpbmNlIEkgbmVlZCB0byB1c2Ugc2NyaXB0cyB3aGVy
ZSBjb21iaW5pbmcgaXMgZXNzZW50aWFsLCBJJ20gc29tZXdoYXQKPiA+IGluY2xpbmVkIHRvIGhp
bGlnaHQgdGhlIGJyb2tlbm5lc3MgaW4gYXBwcyAoYnkgdXNpbmcgY29tYmluaW5nIGNoYXJzCj4g
PiBpbiBtb3JlIHNpdHVhdGlvbnMpIGluIGhvcGVzIHRoYXQgdGhlIGF1dGhvcnMgd2lsbCBmaXgg
dGhlbS4uLgo+Cj4gQXJuZSBHw7Z0amUgKOmrmOebm+iPrykgd3JvdGU6Cj4gPiBJbiB0aGlzIGNh
c2UsICp5b3UqIG5lZWQgdG8gKmRlZmluZSogd2hpY2ggY29tYmluYXRpb25zIHlvdSBuZWVkIGFu
ZAo+ID4gKmhvdyogdGhleSBzaG91bGQgYmUgZGlzcGxheWVkLiBJZiB0aGV5IGV4aXN0IGFscmVh
ZHkgYXMgcHJlLWNvbXBvc2VkCj4gPiBnbHlwaHMgaW4gVW5pY29kZSwgdGhlbiBpdCdzIG5vIHBy
b2JsZW0gdG8gaW1wbGVtZW50IHRoZW0uLi4gYnV0IGlmIG5vdCwKPiA+IGl0J3MgdXAgdG8geW91
IHRvIGRvIHRoZSBkZWZpbml0aW9uIGZpcnN0IGFuZCB0aGVuIGVpdGhlciB0byBtb2RpZnkKPiA+
IGV4aXN0aW5nIGZvbnRzIGJ5IHlvdXJzZWxmIChlLmcuIGJ5IHVzaW5nIGZvbnRmb3JnZSksIG9y
IGFzayB0aGUKPiA+IHVwc3RyZWFtIGF1dGhvciBvZiB0aGUgZm9udHMgdG8gZG8gaXQgZm9yIHlv
dS4KPiA+Cj4gPiBTbywgSSBzdWdnZXN0LCB5b3UgbWFrZSBhIGxpc3Qgb2Ygd2hpY2ggY29tYmlu
YXRpb25zIHlvdSBuZWVkIChhbmQgaG93Cj4gPiB0aGV5IHNob3VsZCBsb29rIGxpa2UpIGFuZCBh
c2sgdGhlIHVwc3RyZWFtIG1haW50YWluZXIgb2YgdGhlIGZvbnQgb2YKPiA+IHlvdXIgY2hvaWNl
IHRvIGltcGxlbWVudCB0aGVtIGZvciB5b3UuIDspCj4gPgo+ID4gSWYgdGhlIGFwcGxpY2F0aW9u
IG9mIHlvdXIgY2hvaWNlIHRoZW4gc3RpbGwgY2Fubm90IGRpc3BsYXkgdGhlCj4gPiBjb21iaW5h
dGlvbnMgY29ycmVjdGx5LCBwcm9kIHRoZSBtYWludGFpbmVycyBvZiB0aGF0IGFwcGxpY2F0aW9u
IHRvCj4gPiBlaXRoZXIgdXNlIGEgcmVuZGVyaW5nIGVuZ2luZSB3aGljaCBjYW4gaW50ZXJwcmV0
IHRoZSBHUE9TIHRhYmxlIG9mIFRURgo+ID4gZm9udHMsIG9yIGhhY2sgdGhlIHN1cHBvcnQgaW4g
YnkgdGhlbXNlbHZlcywgb3IgKHRoZSBiZXN0IHNvbHV0aW9uKQo+ID4gZm9yd2FyZCB0aGUgcmVx
dWVzdCB0byB0aGUgdXBzdHJlYW0gbWFpbnRhaW5lciBvZiB0aGUgcmVuZGVyaW5nIGVuZ2luZQo+
ID4gdGhleSB1c2UuLi4KPgo+IFJpY2ggRmVsa2VyIHdyb3RlOgo+ID4gKm5vZCogdGhlc2UgYXJl
IGFsbCBnb29kIHN1Z2dlc3Rpb25zLgo+IE5vdCBpbiBwcmFjdGljZSwgSSdtIGFmcmFpZC4KPgo+
IEphbiBXaWxsZW0gU3R1bXBlbCB3cm90ZToKPiA+IEluIHRoZSBtZWFudGltZSBJIGZvdW5kIHRo
YXQgbW9zdCBmb250cyBvbiBteSBzeXN0ZW0gZG8gKm5vdCogaGF2ZQo+ID4gdGhpcyB0YWJsZSAo
aW5jbHVkaW5nIHRoZSBCaXRzdHJlYW0gVmVyYSBmb250cyBhbmQgdGhlIE1TICJjb3JlIgo+ID4g
Zm9udHMpLiBJdCBzZWVtcyB0aGF0IGluY2x1ZGluZyBzdWNoIGEgdGFibGUgaXMgb25lIG9mIHRo
ZSB0aGluZ3MKPiA+IHRoYXQgd2UgbXVzdCAiYmFkZ2VyIiB1cHN0cmVhbSBmb250IGRldmVsb3Bl
cnMgYWJvdXQuCj4KPiBJdCB3YXMgaW50ZXJlc3RpbmcgdGhhdCBBcm5lIHBvaW50ZWQgb3V0IHRo
YXQgdGhlIHByb2JsZW0gY291bGQgaW4gdGhlb3J5Cj4gYmUgc29sdmVkIGJ5IGZpeGluZyBmb250
cyBidXQgSSBkb24ndCB0aGluayBpdCdzIGFwcHJvcHJpYXRlCj4gdG8gc2hpZnQgdGhlIHRhc2sg
b2YgZml4aW5nIHRoZSBpc3N1ZSB0byBmb250cyBhbmQgdGhlaXIgcHJvdmlkZXJzLAo+IGJlY2F1
c2UgdGhhdCBhcHByb2FjaCBpcyBub3QgcmVsaWFibGUgYW5kIG5vdCBwcmFjdGljYWwgZ2l2ZW4g
dGhlCj4gaHVnZSBudW1iZXIgb2YgZXhpc3RpbmcgZm9udHMgYW5kIHRoZSBzbWFsbCBudW1iZXIg
b2YgcmVuZGVyaW5nIGVuZ2luZXMuCj4KPiBSYXRoZXIgYSBmb250IHJlbmRlcmluZyBlbmdpbmUg
c2hvdWxkIGRvIHRoZSBmb2xsb3dpbmc6Cj4gKiBJZiBhbmNob3IgcG9pbnRzIGFyZSBkZWZpbmVk
IGluIHRoZSBmb250LCB0aGV5IHNob3VsZCBvZiBjb3Vyc2UKPiAgIGJlIHVzZWQuCj4gKiBJbiBh
YnNlbmNlIG9mIGFwcHJvcHJpYXRlIGZvbnQgaW5mb3JtYXRpb24sIHRoZSByZW5kZXJpbmcgZW5n
aW5lCj4gICBzaG91bGQgZGV0ZXJtaW5lIHRoZSBib3VuZGluZyBib3hlcyBvZiBiYXNlIGNoYXJh
Y3RlciBhbmQgYWNjZW50KHMpCj4gICB3aGljaCBzaG91bGQgZWFzaWx5IGVuYWJsZSBpdCB0byBh
cHBseSBzb21lIGtpbmQgb2YgYmVzdC1ndWVzcwo+ICAgYXBwcm9hY2ggdG8gcGxhY2UgdGhlIGFj
Y2VudCB0byBhIHByb3BlciBsb2NhdGlvbi4KPiAgIFRoZSBlbmdpbmUgc2hvdWxkIG1haW50YWlu
IGEgbGlzdCBvZiB3aGljaCBhY2NlbnRzIGFyZSAobm9ybWFsbHkpCj4gICBwbGFjZWQgb24gdG9w
IG9yIGJlbG93LCBhbmQgd2hldGhlciB0aGUgc3RhbmRhcmQgcG9zaXRpb24gaXMKPiAgIHdpdGgg
YSBnYXAgb3Igbm90IChzb21ldGltZXMgYmVsb3cpLCBjZW50ZXJlZCBvciBhdHRhY2hlZCB0byBh
biBlZGdlLgo+ICAgRm9yIGl0YWxpYyBvciBvYmxpcXVlIGZvbnRzLCB0aGUgc2xhbnRpbmcgYW5n
bGUgc2hvdWxkIGJlIGNvbnNpZGVyZWQKPiAgIGZvciBiZXN0IHBvc3NpYmxlIHBsYWNlbWVudC4K
PiAqIElmIHRoZSBmb250IGRvZXMgbm90IGNvbnRhaW4gdGhlIGFwcHJvcHJpYXRlIGFjY2VudCBh
bmQgdGhlCj4gICByZW5kZXJpbmcgZW5naW5lIHByb3ZpZGVzIHRoZSBmZWF0dXJlIG9mIGZvbnQg
c3Vic3RpdHV0aW9uLCB0aGUKPiAgIGFjY2VudCBzaG91bGQgYmUgdGFrZW4gZnJvbSBhIGRpZmZl
cmVudCBmb250LiBGb3IgbWF4aW1hbAo+ICAgY29uc2lzdGVuY3kgb2Ygc3R5bGUsIG5laXRoZXIg
dGhlIGJhc2UgY2hhcmFjdGVyIG5vciBhIHByZWNvbXBvc2VkCj4gICBjaGFyYWN0ZXIgc2hvdWxk
IGJlIHRha2VuIGZyb20gdGhhdCBvdGhlciBmb250ICh1bmxlc3MgdGhlIGJhc2UKPiAgIGNoYXJh
Y3RlciBpdHNlbGYgaXMgbWlzc2luZyBpbiB0aGUgY3VycmVudCBmb250KS4KPgo+IEkgYWN0dWFs
bHkgaW1wbGVtZW50ZWQgYW4gYXV0b21hdGljIGFjY2VudCBwbGFjZW1lbnQgYWxnb3JpdGhtIG15
c2VsZgo+IHF1aXRlIGEgd2hpbGUgYWdvIGZvciBmaXhpbmcgUG9zdFNjcmlwdCBmb250czsgSSB3
cm90ZSBhIFBvc3RTY3JpcHQKPiBwcm9ncmFtIHRoYXQgd291bGQgY29tcG9zZSB0aGUgTGF0aW4t
MSBzZXQgb2YgY29tYmluZWQgY2hhcmFjdGVycyBmcm9tCj4gYmFzZSBsZXR0ZXJzIGFuZCBhY2Nl
bnRzIGF1dG9tYXRpY2FsbHkgYW5kIHNhdmUgYW4gdXBkYXRlZCBQb3N0U2NyaXB0Cj4gZm9udC4g
VGhpcyB3YXkgSSBjb3VsZCBtYWtlIHVzZSBvZiB0aGUgbWFueSBmcmVlIFBvc3RTY3JpcHQgZm9u
dHMgdGhhdAo+IHVzZWQgdG8gYmUgbWFkZSBieSBhbWF0ZXVycywgb2Z0ZW4ganVzdCBjb250YWlu
aW5nIHRoZSBBZG9iZSBzdGFuZGFyZAo+IGVuY29kaW5nIGNoYXJhY3RlcnMuCj4KPiBLaW5kIHJl
Z2FyZHMsCj4gVGhvbWFzCj4KPgo+Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+IFRha2UgU3VydmV5cy4g
RWFybiBDYXNoLiBJbmZsdWVuY2UgdGhlIEZ1dHVyZSBvZiBJVAo+IEpvaW4gU291cmNlRm9yZ2Uu
bmV0J3MgVGVjaHNheSBwYW5lbCBhbmQgeW91J2xsIGdldCB0aGUgY2hhbmNlIHRvIHNoYXJlIHlv
dXIKPiBvcGluaW9ucyBvbiBJVCAmIGJ1c2luZXNzIHRvcGljcyB0aHJvdWdoIGJyaWVmIHN1cnZl
eXMgLSBhbmQgZWFybiBjYXNoCj4gaHR0cDovL3d3dy50ZWNoc2F5LmNvbS9kZWZhdWx0LnBocD9w
YWdlPWpvaW4ucGhwJnA9c291cmNlZm9yZ2UmQ0lEPURFVkRFVgo+Cj4gX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBQYXBzLWRpc2N1c3MgbWFpbGluZyBs
aXN0Cj4gUGFwcy1kaXNjdXNzQGxpc3RzLnNvdXJjZWZvcmdlLm5ldAo+IGh0dHBzOi8vbGlzdHMu
c291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL3BhcHMtZGlzY3Vzcwo+Cj4KPgo=

[Paps-discuss] (no subject)

[Thomas W. <to...@to...>]

Arne Götje (高盛華) wrote:
> The fonts need to contain a) the base glyphs b) the combining 
> accents c) "anchors" in the GPOS table to tell the rendering 
> engine where exactly to place the accents. In fontforge this is
> done easily. :)

Jan Willem Stumpel wrote:
> ...
> So the advice to users has to remain: use pre-combined accents
> whenever possible. Don't count on the "combining accents"
> mechanism to work. It won't, except from some lucky cases.

Arne Götje (高盛華) wrote:
> yes, it depends totally on the font to define the *position* of the
> accents (and weather or not they can be stacked). But it depends on the
> rendering engine to *interpret* the information the font gives about the
> accents.
> 
> BTW: there was no irony in my statement. In Fontforge it is really easy
> to define the "anchors". For all pre-composed Latin based combinations,
> you can get it done with around 10 anchor classes, including the stacked
> ones for Vietnamese.
> 
> The difficulty is to decide how the combinations should be displayed,
> i.e. which "standard" to follow and which scripts to support.
> You need to define the anchor points, both for the base glyphs and the
> combining accents, separately and for each possible combination. This is
> quite some work...

Rich Felker wrote:
> Well there are two flip sides to this situation. On the one hand
> you're right, but on the other hand if no one tries to use the
> combining characters, applications and fonts will remain broken. :(
> Since I need to use scripts where combining is essential, I'm somewhat
> inclined to hilight the brokenness in apps (by using combining chars
> in more situations) in hopes that the authors will fix them...

Arne Götje (高盛華) wrote:
> In this case, *you* need to *define* which combinations you need and
> *how* they should be displayed. If they exist already as pre-composed
> glyphs in Unicode, then it's no problem to implement them... but if not,
> it's up to you to do the definition first and then either to modify
> existing fonts by yourself (e.g. by using fontforge), or ask the
> upstream author of the fonts to do it for you.
> 
> So, I suggest, you make a list of which combinations you need (and how
> they should look like) and ask the upstream maintainer of the font of
> your choice to implement them for you. ;)
>
> If the application of your choice then still cannot display the
> combinations correctly, prod the maintainers of that application to
> either use a rendering engine which can interpret the GPOS table of TTF
> fonts, or hack the support in by themselves, or (the best solution)
> forward the request to the upstream maintainer of the rendering engine
> they use...

Rich Felker wrote:
> *nod* these are all good suggestions.
Not in practice, I'm afraid.

Jan Willem Stumpel wrote:
> In the meantime I found that most fonts on my system do *not* have
> this table (including the Bitstream Vera fonts and the MS "core"
> fonts). It seems that including such a table is one of the things
> that we must "badger" upstream font developers about.

It was interesting that Arne pointed out that the problem could in theory 
be solved by fixing fonts but I don't think it's appropriate 
to shift the task of fixing the issue to fonts and their providers, 
because that approach is not reliable and not practical given the 
huge number of existing fonts and the small number of rendering engines.

Rather a font rendering engine should do the following:
* If anchor points are defined in the font, they should of course 
  be used.
* In absence of appropriate font information, the rendering engine 
  should determine the bounding boxes of base character and accent(s) 
  which should easily enable it to apply some kind of best-guess 
  approach to place the accent to a proper location.
  The engine should maintain a list of which accents are (normally) 
  placed on top or below, and whether the standard position is 
  with a gap or not (sometimes below), centered or attached to an edge.
  For italic or oblique fonts, the slanting angle should be considered 
  for best possible placement.
* If the font does not contain the appropriate accent and the 
  rendering engine provides the feature of font substitution, the 
  accent should be taken from a different font. For maximal 
  consistency of style, neither the base character nor a precomposed 
  character should be taken from that other font (unless the base 
  character itself is missing in the current font).

I actually implemented an automatic accent placement algorithm myself 
quite a while ago for fixing PostScript fonts; I wrote a PostScript 
program that would compose the Latin-1 set of combined characters from 
base letters and accents automatically and save an updated PostScript 
font. This way I could make use of the many free PostScript fonts that 
used to be made by amateurs, often just containing the Adobe standard 
encoding characters.

Kind regards,
Thomas

Re: [Paps-discuss] Combining characters not rendered properly

[<ar...@li...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jan Willem Stumpel wrote:
> Arne Götje (高盛華) wrote:
>> [..] yes, it depends totally on the font to define the
>> *position* of the accents (and weather or not they can be
>> stacked). But it depends on the rendering engine to *interpret*
>> the information the font gives about the accents.
>>
>> BTW: there was no irony in my statement. In Fontforge it is
>> really easy to define the "anchors". For all pre-composed Latin
>> based combinations, you can get it done with around 10 anchor
>> classes, including the stacked ones for Vietnamese.
> 
> Is it also easy to create a GPOS table for a font which does not
> have one? My experience with Fontforge is very limited!

As soon as any GPOS feature ("anchors" is one if the features) is
present, the table is created automatically.

> In the meantime I found that most fonts on my system do *not* have
> this table (including the Bitstream Vera fonts and the MS "core"
> fonts). It seems that including such a table is one of the things
> that we must "badger" upstream font developers about.

Exactly.

>> [..] Example: o <U+0301> <U+0358> -> ó͘
> 
> This example displays OK on my system with your uming.ttf font
> (naturally), but also (by "luck") with, for instance, Bitstream
> Vera Serif (which does not have the combining accent characters,
> nor a GPOS table). I suppose the rendering engine (pango) borrows
> the accents from another font (yours, probably). But how can it
> know where to place them? The base characters in Bitstream Vera
> Serif do not have anchors.

This also puzzles me. but the glyphs do not come from my font, they look
different... I'd have to take a closer look on the fonts if I find some
time... I assume that if there are no GPOS information present, pango
and other rendering engines classify the combining accents by unicode
coderange and just center them over the preceding (latin) character...
(maybe someone of the pango guys can answer this...?)

Cheers
Arne
- --
Arne Götje (高盛華) <ar...@li...>
PGP/GnuPG key: 1024D/685D1E8C
Fingerprint: 2056 F6B7 DEA8 B478 311F  1C34 6E9F D06E 685D 1E8C
Key available at wwwkeys.pgp.net.   Encrypted e-mail preferred.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFfS5Ybp/QbmhdHowRApPWAJsESNwk1M29ngc8op6Uf1RRJVnDBwCgmEOR
grh/GERXv0DrzsqXj+ousV8=
=m8wc
-----END PGP SIGNATURE-----

Re: [Paps-discuss] Combining characters not rendered properly

[Jan W. S. <jst...@pl...>]

Arne G=C3=B6tje (=E9=AB=98=E7=9B=9B=E8=8F=AF) wrote:
> [..] yes, it depends totally on the font to define the
> *position* of the accents (and weather or not they can be
> stacked). But it depends on the rendering engine to *interpret*
> the information the font gives about the accents.
>=20
> BTW: there was no irony in my statement. In Fontforge it is
> really easy to define the "anchors". For all pre-composed Latin
> based combinations, you can get it done with around 10 anchor
> classes, including the stacked ones for Vietnamese.

Is it also easy to create a GPOS table for a font which does not
have one? My experience with Fontforge is very limited!

In the meantime I found that most fonts on my system do *not* have
this table (including the Bitstream Vera fonts and the MS "core"
fonts). It seems that including such a table is one of the things
that we must "badger" upstream font developers about.

> [..] Example: o <U+0301> <U+0358> -> o=CC=81=CD=98

This example displays OK on my system with your uming.ttf font
(naturally), but also (by "luck") with, for instance, Bitstream
Vera Serif (which does not have the combining accent characters,
nor a GPOS table). I suppose the rendering engine (pango) borrows
the accents from another font (yours, probably). But how can it
know where to place them? The base characters in Bitstream Vera
Serif do not have anchors.

Regards, Jan