Re[2]: Backgrounds

Re[2]: Backgrounds

[Hans Hagen]

At 07:52 PM 3/24/2003 +0100, you wrote:

>Actually I did have a look at it (assuming you're talking about
>textbackgrounds), but I found their behaviour to be rather
>different from that of backgrounds even when location=paragraph.
>For example, setting frame=on doesn't give me a frame, and it
>doesn't seem to support rounded corners for neither the background
>nor the frame. Also, setting a largish offset "covers" the text
>that precedes the background, and this isn't nice at all. I think
>that textbackgrounds and backgrounds serve different purpouses.
>
>And what about the other requests? (Behaviour at splits, different
>corner styles)

\starttext

\setupcolors[state=start]

\definetextbackground[gb][state=start]

\startuseMPgraphic{mpos:par:columnset}
   for i := 1 upto nofmultipars :
     fill multipars[i] enlarged 5pt cornered 5pt withcolor green ;
     draw multipars[i] enlarged 5pt cornered 5pt withcolor red ;
   endfor ;
\stopuseMPgraphic

\input tufte \blank
\starttextbackground[gb]
\dorecurse{10}{\input tufte \par}
\stoptextbackground
\blank \input tufte

\stoptext

they split, can have corners, lay behind the text, ...

only some spacing issues need to be solved (working on that on and off)

Hans
-------------------------------------------------------------------------
                                   Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                       Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
  tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------
                        information: http://www.pragma-ade.com/roadmap.pdf
                     documentation: http://www.pragma-ade.com/showcase.pdf
-------------------------------------------------------------------------

Re[3]: Backgrounds

[Giuseppe Bilotta]

Tuesday, March 25, 2003 Hans Hagen wrote:

HH> \starttext

HH> \setupcolors[state=start]

HH> \definetextbackground[gb][state=start]

HH> \startuseMPgraphic{mpos:par:columnset}
HH>    for i := 1 upto nofmultipars :
HH>      fill multipars[i] enlarged 5pt cornered 5pt withcolor green ;
HH>      draw multipars[i] enlarged 5pt cornered 5pt withcolor red ;
HH>    endfor ;
HH> \stopuseMPgraphic

HH> \input tufte \blank
HH> \starttextbackground[gb]
HH> \dorecurse{10}{\input tufte \par}
HH> \stoptextbackground
HH> \blank \input tufte

HH> \stoptext

HH> they split, can have corners, lay behind the text, ...

Ok, I start to see the picture: one must use MetaPost. I can
accept that :) (even if it's somewhat clumsier, but this is no
problem, one can write interfaces for that).

The problem is still that I cannot separate the behaviour at the
end of the background from the behaviour at a split. What I'm
looking for is something like this:


/-------------------------------\
| text text text text text text |
| text text text text text text |
| text text text text text text |
| text text text text text text |

---- (page split) --------------

| text text text text text text |
| text text text text text text |
| text text text text text text |
| text text text text text text |
\-------------------------------/

Instead, what I get is this:

/-------------------------------\
| text text text text text text |
| text text text text text text |
| text text text text text text |
| text text text text text text |
\-------------------------------/

---- (page split) --------------

/-------------------------------\
| text text text text text text |
| text text text text text text |
| text text text text text text |
| text text text text text text |
\-------------------------------/


Can the first effect be achieved?

-- 
Giuseppe "Oblomov" Bilotta

Re[3]: Backgrounds

[Hans Hagen]

At 11:43 AM 3/25/2003 +0100, Giuseppe Bilotta wrote:

>Ok, I start to see the picture: one must use MetaPost. I can
>accept that :) (even if it's somewhat clumsier, but this is no
>problem, one can write interfaces for that).

actually, it's handier once you get going; otherwise you would be limited 
to simple frames and backgrounds, simply because we would run out of 
keywords for options and/or forget to documen them; i expect to provide a 
library of backgrounds in due time

>The problem is still that I cannot separate the behaviour at the
>end of the background from the behaviour at a split. What I'm
>looking for is something like this:

guess what, this time your demands for features are fulfilled on forehand!

there is an array available

   multilocs[...]

1 = top
2 = mid
3 = bottom

shape; this is how i could handle the example in details with different 
shades per kind of frame

>Can the first effect be achieved?

as said,

Hans
-------------------------------------------------------------------------
                                   Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                       Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
  tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------
                        information: http://www.pragma-ade.com/roadmap.pdf
                     documentation: http://www.pragma-ade.com/showcase.pdf
-------------------------------------------------------------------------

Re[4]: Backgrounds

[Giuseppe Bilotta]

Tuesday, March 25, 2003 Hans Hagen wrote:
>>The problem is still that I cannot separate the behaviour at the
>>end of the background from the behaviour at a split. What I'm
>>looking for is something like this:

HH> guess what, this time your demands for features are fulfilled on forehand!

HH> there is an array available

HH>    multilocs[...]

HH> 1 = top
HH> 2 = mid
HH> 3 = bottom

HH> shape; this is how i could handle the example in details with different
HH> shades per kind of frame

Almost perfect! Only a few things need refining:

(1) "top" is also used when there is no split; it should be
possible to detect the "no-split" situation (multilocs=0?)

(2) I still need a to find a way to make only certain corners
rounded, but I guess that's just a matter of MetaPosting a little.

Up to now, I came up with the following:

\starttext

\setupcolors[state=start]

\definetextbackground[gb][state=start]

\startuseMPgraphic{mpos:par:columnset}
   path p, q;
   for i := 1 upto nofmultipars :
     p := counterclockwise simplified multipars[i] leftenlarged 5pt rightenlarged 5pt ;
     if multilocs[i] = 1 :
       q := p topenlarged 5pt ;
       fill q withcolor green ;
       draw topboundary q withcolor red ;
       draw leftboundary q withcolor red ;
       draw rightboundary q withcolor red ;
     elseif multilocs[i] = 2 :
       q := p ;
       fill q withcolor green ;
       draw leftboundary q withcolor red ;
       draw rightboundary q withcolor red ;
     else:
       q := p bottomenlarged 5pt;
       fill q withcolor green ;
       draw bottomboundary q withcolor red ;
       draw leftboundary q withcolor red ;
       draw rightboundary q withcolor red ;
     fi
   endfor ;
\stopuseMPgraphic

\starttextbackground[gb]
\input tufte
\stoptextbackground

\blank[2*big]

\starttextbackground[gb]
\dorecurse{10}{\input tufte \par}
\stoptextbackground
\blank \input tufte

\stoptext

As you can see, the first background doesn't split and behaves
like multilocs=1, while one would wish it to behave differently.

-- 
Giuseppe "Oblomov" Bilotta

Re[4]: Backgrounds

[Hans Hagen]

At 03:36 PM 3/25/2003 +0100, you wrote:
>Tuesday, March 25, 2003 Hans Hagen wrote:
> >>The problem is still that I cannot separate the behaviour at the
> >>end of the background from the behaviour at a split. What I'm
> >>looking for is something like this:
>
>HH> guess what, this time your demands for features are fulfilled on forehand!
>
>HH> there is an array available
>
>HH>    multilocs[...]
>
>HH> 1 = top
>HH> 2 = mid
>HH> 3 = bottom
>
>HH> shape; this is how i could handle the example in details with different
>HH> shades per kind of frame
>
>Almost perfect! Only a few things need refining:
>
>(1) "top" is also used when there is no split; it should be
>possible to detect the "no-split" situation (multilocs=0?)

(hm, would not be upward compatible)

2 can be used for that

Hans
-------------------------------------------------------------------------
                                   Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                       Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
  tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------
                        information: http://www.pragma-ade.com/roadmap.pdf
                     documentation: http://www.pragma-ade.com/showcase.pdf
-------------------------------------------------------------------------

Re[5]: Backgrounds

[Giuseppe Bilotta]

Tuesday, March 25, 2003 Hans Hagen wrote:
>>Almost perfect! Only a few things need refining:
>>
>>(1) "top" is also used when there is no split; it should be
>>possible to detect the "no-split" situation (multilocs=0?)

HH> (hm, would not be upward compatible)

Then add a issplit boolean.

-- 
Giuseppe "Oblomov" Bilotta

Re: Backgrounds

[Patrick Gundlach]

Giuseppe Bilotta <gip.bilotta@iol.it> writes:

Hello Giuseppe,

> \startuseMPgraphic{mpos:par:columnset}
>    path p, q;
>    for i := 1 upto nofmultipars :
>      p := counterclockwise simplified multipars[i] leftenlarged 5pt
>    rightenlarged 5pt ;

why did you use "counterclockwise simplified..." ? What is this?


Patrick

Re[2]: Backgrounds

[Giuseppe Bilotta]

Wednesday, April 9, 2003 Patrick Gundlach wrote:

PG> Giuseppe Bilotta <gip.bilotta@iol.it> writes:

PG> Hello Giuseppe,

>> \startuseMPgraphic{mpos:par:columnset}
>>    path p, q;
>>    for i := 1 upto nofmultipars :
>>      p := counterclockwise simplified multipars[i] leftenlarged 5pt
>>    rightenlarged 5pt ;

PG> why did you use "counterclockwise simplified..." ? What is this?

I used that to make sure that p didn't have extra points
(simplified) and went in a specific direction (counterclockwise);
anyway, I rewrote my code:

===

\starttext

\setupcolors[state=start]

\definetextbackground[gb][state=start]

\startuseMPgraphic{mpos:par:columnset}
   pair urc, ulc, llc, lrc ; % corners
   path urcp, ulcp, llcp, lrcp ; % paths
   path q ;
   cornerradius := 5pt ;
   offset := 7.5pt ;
   color framecolor, backgroundcolor ;
   pen framepen ;
   framecolor := red ;
   framepen := pensquare rotated 45 ;
   framethickness := 2pt ;
   backgroundcolor := lightgray ;
   for i := 1 upto nofmultipars :
     urc := urcorner multipars[i] + (offset, offset) ;
     ulc := ulcorner multipars[i] + (-offset, offset) ;
     llc := llcorner multipars[i] + (-offset, -offset) ;
     lrc := lrcorner multipars[i] + (offset, -offset) ;
     ulcp := quartercircle
             rotated 90
             scaled (2*cornerradius)
             shifted (ulc + (cornerradius, -cornerradius)) ;
     urcp := quartercircle
             scaled (2*cornerradius)
             shifted (urc + (-cornerradius, -cornerradius)) ;
     llcp := quartercircle
             rotated 180
             scaled (2*cornerradius)
             shifted (llc + (cornerradius, cornerradius)) ;
     lrcp := quartercircle
             rotated -90
             scaled (2*cornerradius)
             shifted (lrc + (-cornerradius, cornerradius)) ;
     if multilocs[i] = 1 : % top
       q := lrc -- urcp -- ulcp -- llc ;
       fill q--cycle
            withcolor backgroundcolor ;
       draw q
            withcolor framecolor
            withpen framepen scaled framethickness ;
     elseif multilocs[i] = 2 :
       fill llc -- lrc -- urc -- ulc -- cycle
            withcolor backgroundcolor ;
       draw ulc -- llc
            withcolor framecolor
            withpen framepen scaled framethickness ;
       draw lrc -- urc
            withcolor framecolor
            withpen framepen scaled framethickness ;
     else:
       q := ulc -- llcp -- lrcp -- urc ;
       fill q--cycle
            withcolor backgroundcolor ;
       draw q
            withcolor framecolor
            withpen framepen scaled framethickness ;
     fi
   endfor ;
\stopuseMPgraphic

\starttextbackground[gb]
\input tufte
\stoptextbackground

\blank[2*big]

\starttextbackground[gb]
\dorecurse{5}{\input tufte \par}
\stoptextbackground
\blank \input tufte

\stoptext

===

Now the only thing we need is a way to know when the background is
split and when it's not. Hans?

-- 
Giuseppe "Oblomov" Bilotta

Re: Backgrounds

[Patrick Gundlach]

Giuseppe Bilotta <gip.bilotta@iol.it> writes:

Hello Giuseppe,

> PG> why did you use "counterclockwise simplified..." ? What is this?
>
> I used that to make sure that p didn't have extra points
> (simplified) and went in a specific direction (counterclockwise);
> anyway, I rewrote my code:

Well, does it have to be simplified? Is there a chance that there are
unwanted (extra) points?

BTW: that looks very nice.


PAT

Re[2]: Backgrounds

[Giuseppe Bilotta]

Thursday, April 10, 2003 Patrick Gundlach wrote:
>> PG> why did you use "counterclockwise simplified..." ? What is this?
>>
>> I used that to make sure that p didn't have extra points
>> (simplified) and went in a specific direction (counterclockwise);
>> anyway, I rewrote my code:

PG> Well, does it have to be simplified? Is there a chance that there are
PG> unwanted (extra) points?

Actually I have no idea! I just wanted to be on the safe side of
things :)

PG> BTW: that looks very nice.

Yes, I think so too ;) Thanks. Feel free to use it as needed. I
tried to make it as parametric as possible. As soon as Hans
provides the hook to determine if the background split or not I'll
try to package it into a module.

-- 
Giuseppe "Oblomov" Bilotta

Re: Backgrounds

[Johannes Hüsing]

Patrick Gundlach <pg@levana.de> [Thu, Apr 10, 2003 at 11:50:43AM CEST]:
[...]
> 
> BTW: that looks very nice.

I am only loosely following here, but after processing Giuseppe's
file I get the following output 

http://www.panix.com/~derwisch/hannes/tex/giuseppe.pdf

and I don't think this is what Giuseppe intended.

(This is pdfeTeX, Version 3.14159-1.00b-pretest-20020211-2.1)
(ConTeXt  ver: 2003.1.28  fmt: 2003.1.28)

Greetings


Johannes
-- 
Johannes Hüsing   There is something fascinating about science. One gets
hannes@ruhrau.de  such wholesale returns of conjecture from such a 
                  trifling investment of fact.                Mark Twain

Re[2]: Backgrounds

[Giuseppe Bilotta]

Friday, April 18, 2003 Johannes Hüsing wrote:

JH> Patrick Gundlach <pg@levana.de> [Thu, Apr 10, 2003 at 11:50:43AM CEST]:
JH> [...]
>> 
>> BTW: that looks very nice.

JH> I am only loosely following here, but after processing Giuseppe's
JH> file I get the following output 

JH> http://www.panix.com/~derwisch/hannes/tex/giuseppe.pdf

JH> and I don't think this is what Giuseppe intended.

JH> (This is pdfeTeX, Version 3.14159-1.00b-pretest-20020211-2.1)
JH> (ConTeXt  ver: 2003.1.28  fmt: 2003.1.28)

Well, that's not what I get, running ConTeXt 2003.3.17 on pdfeTeX
3.141592-1.10b-2.1

-- 
Giuseppe "Oblomov" Bilotta

Re: Backgrounds

[Patrick Gundlach]

Johannes Hüsing <hannes@ruhrau.de> writes:

Hi

> and I don't think this is what Giuseppe intended.

:) right. Did you run context often enough? (Well, one texexec run
should do)


> (This is pdfeTeX, Version 3.14159-1.00b-pretest-20020211-2.1)
> (ConTeXt  ver: 2003.1.28  fmt: 2003.1.28)

This is pdfeTeX, Version 3.14159-1.10b-2.1 (Web2C 7.4.5)
ConTeXt  ver: 2003.3.17  fmt: 2003.3.18

Patrick

Re[2]: Backgrounds

[Hans Hagen]

At 18:57 09/04/2003 +0200, you wrote:
>Wednesday, April 9, 2003 Patrick Gundlach wrote:
>
>PG> Giuseppe Bilotta <gip.bilotta@iol.it> writes:
>
>PG> Hello Giuseppe,
>
> >> \startuseMPgraphic{mpos:par:columnset}
> >>    path p, q;
> >>    for i := 1 upto nofmultipars :
> >>      p := counterclockwise simplified multipars[i] leftenlarged 5pt
> >>    rightenlarged 5pt ;
>
>PG> why did you use "counterclockwise simplified..." ? What is this?
>
>I used that to make sure that p didn't have extra points
>(simplified) and went in a specific direction (counterclockwise);
>anyway, I rewrote my code:

which can be simplified to:

\startuseMPgraphic{mpos:par:columnset}
    path q ; picture r ; color framecolor, backgroundcolor ;
    cornerradius := 5pt ; offset := 7.5pt ;
    framecolor := red ; framethickness := 2pt ;
    backgroundcolor := lightgray ;
    for i := 1 upto nofmultipars :
      multipars[i] := multipars[i] enlarged offset ;
      if multilocs[i] = 1 : % top
        q := multipars[i] bottomenlarged (4cornerradius) ;
      elseif multilocs[i] = 2 :
        q := multipars[i] bottomenlarged (4cornerradius) ;
        q := q topenlarged (4cornerradius) ;
      else:
        q := multipars[i] topenlarged (4cornerradius) ;
      fi ;
      q := q smoothed (2cornerradius) ;
      r := image
        ( fill q withcolor backgroundcolor ;
          draw q withcolor framecolor
            withpen pencircle scaled framethickness ; ) ;
      clip r to boundingbox multipars[i] ;
      addto currentpicture also r ;
    endfor ;
\stopuseMPgraphic

watch the usage of "enlarged" and the "smoothed"

Hans


>===
>
>\starttext
>
>\setupcolors[state=start]
>
>\definetextbackground[gb][state=start]
>
>\startuseMPgraphic{mpos:par:columnset}
>    pair urc, ulc, llc, lrc ; % corners
>    path urcp, ulcp, llcp, lrcp ; % paths
>    path q ;
>    cornerradius := 5pt ;
>    offset := 7.5pt ;
>    color framecolor, backgroundcolor ;
>    pen framepen ;
>    framecolor := red ;
>    framepen := pensquare rotated 45 ;
>    framethickness := 2pt ;
>    backgroundcolor := lightgray ;
>    for i := 1 upto nofmultipars :
>      urc := urcorner multipars[i] + (offset, offset) ;
>      ulc := ulcorner multipars[i] + (-offset, offset) ;
>      llc := llcorner multipars[i] + (-offset, -offset) ;
>      lrc := lrcorner multipars[i] + (offset, -offset) ;
>      ulcp := quartercircle
>              rotated 90
>              scaled (2*cornerradius)
>              shifted (ulc + (cornerradius, -cornerradius)) ;
>      urcp := quartercircle
>              scaled (2*cornerradius)
>              shifted (urc + (-cornerradius, -cornerradius)) ;
>      llcp := quartercircle
>              rotated 180
>              scaled (2*cornerradius)
>              shifted (llc + (cornerradius, cornerradius)) ;
>      lrcp := quartercircle
>              rotated -90
>              scaled (2*cornerradius)
>              shifted (lrc + (-cornerradius, cornerradius)) ;
>      if multilocs[i] = 1 : % top
>        q := lrc -- urcp -- ulcp -- llc ;
>        fill q--cycle
>             withcolor backgroundcolor ;
>        draw q
>             withcolor framecolor
>             withpen framepen scaled framethickness ;
>      elseif multilocs[i] = 2 :
>        fill llc -- lrc -- urc -- ulc -- cycle
>             withcolor backgroundcolor ;
>        draw ulc -- llc
>             withcolor framecolor
>             withpen framepen scaled framethickness ;
>        draw lrc -- urc
>             withcolor framecolor
>             withpen framepen scaled framethickness ;
>      else:
>        q := ulc -- llcp -- lrcp -- urc ;
>        fill q--cycle
>             withcolor backgroundcolor ;
>        draw q
>             withcolor framecolor
>             withpen framepen scaled framethickness ;
>      fi
>    endfor ;
>\stopuseMPgraphic
>
>\starttextbackground[gb]
>\input tufte
>\stoptextbackground
>
>\blank[2*big]
>
>\starttextbackground[gb]
>\dorecurse{5}{\input tufte \par}
>\stoptextbackground
>\blank \input tufte
>
>\stoptext
>
>===
>
>Now the only thing we need is a way to know when the background is
>split and when it's not. Hans?
>
>--
>Giuseppe "Oblomov" Bilotta
>
>
>
>_______________________________________________
>ntg-context mailing list
>ntg-context@ntg.nl
>http://www.ntg.nl/mailman/listinfo/ntg-context
>
>================================================================
>Deze e-mail is door E-mail VirusScanner van Planet Internet gecontroleerd 
>op virussen.
>Op http://www.planet.nl/evs staat een verwijzing naar de actuele lijst 
>waar op wordt gecontroleerd.

-------------------------------------------------------------------------
                                   Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                       Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
  tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------
                        information: http://www.pragma-ade.com/roadmap.pdf
                     documentation: http://www.pragma-ade.com/showcase.pdf
-------------------------------------------------------------------------

Re[3]: Backgrounds

[Giuseppe Bilotta]

Thursday, April 10, 2003 Hans Hagen wrote:

HH> \startuseMPgraphic{mpos:par:columnset}
HH>     path q ; picture r ; color framecolor, backgroundcolor ;
HH>     cornerradius := 5pt ; offset := 7.5pt ;
HH>     framecolor := red ; framethickness := 2pt ;
HH>     backgroundcolor := lightgray ;
HH>     for i := 1 upto nofmultipars :
HH>       multipars[i] := multipars[i] enlarged offset ;
HH>       if multilocs[i] = 1 : % top
HH>         q := multipars[i] bottomenlarged (4cornerradius) ;
HH>       elseif multilocs[i] = 2 :
HH>         q := multipars[i] bottomenlarged (4cornerradius) ;
HH>         q := q topenlarged (4cornerradius) ;
HH>       else:
HH>         q := multipars[i] topenlarged (4cornerradius) ;
HH>       fi ;
HH>       q := q smoothed (2cornerradius) ;
HH>       r := image
HH>         ( fill q withcolor backgroundcolor ;
HH>           draw q withcolor framecolor
HH>             withpen pencircle scaled framethickness ; ) ;
HH>       clip r to boundingbox multipars[i] ;
HH>       addto currentpicture also r ;
HH>     endfor ;
HH> \stopuseMPgraphic

HH> watch the usage of "enlarged" and the "smoothed"

I think I see; instead of drawing only the needed parts you draw
the whole frame and then cut the unwanted parts off. Is this more
efficient than drawing only the needed parts?

And what about the way to determine when there is a split or not?
Could you please put a boolean that reveals it, in the next beta?
(even if I'm still convinced that using a multilocs of 0 would be
enough ... ok, it would break backwards compatibility, but how
many people are using this mechanism already?)

-- 
Giuseppe "Oblomov" Bilotta

Re[3]: Backgrounds

[Hans Hagen]

At 15:35 11/04/2003 +0200, Giuseppe Bilotta wrote:

>I think I see; instead of drawing only the needed parts you draw
>the whole frame and then cut the unwanted parts off. Is this more
>efficient than drawing only the needed parts?

simplier, less error prone, less code, more educative ...

>And what about the way to determine when there is a split or not?
>Could you please put a boolean that reveals it, in the next beta?
>(even if I'm still convinced that using a multilocs of 0 would be
>enough ... ok, it would break backwards compatibility, but how
>many people are using this mechanism already?)

hm, but as a heavy context user i count myself as 2048 users so ...

Hans
-------------------------------------------------------------------------
                                   Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                       Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
  tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------
                        information: http://www.pragma-ade.com/roadmap.pdf
                     documentation: http://www.pragma-ade.com/showcase.pdf
-------------------------------------------------------------------------

Re: Backgrounds

[Patrick Gundlach]

Hans Hagen <pragma@wxs.nl> writes:
Hi,

> hm, but as a heavy context user i count myself as 2048 users so ...

Oh, too bad; I wanted to suggest that the (some) ConTeXt users vote on
this ;-) G.B. and I pro and you against it -> clear majority for
multilocs=0 ;-) But that way we are clearly outnumbered.

Patrick

Re[4]: Backgrounds

[Giuseppe Bilotta]

Friday, April 11, 2003 Hans Hagen wrote:

>>I think I see; instead of drawing only the needed parts you draw
>>the whole frame and then cut the unwanted parts off. Is this more
>>efficient than drawing only the needed parts?

HH> simplier, less error prone, less code, more educative ...

Fine :)

>>And what about the way to determine when there is a split or not?
>>Could you please put a boolean that reveals it, in the next beta?
>>(even if I'm still convinced that using a multilocs of 0 would be
>>enough ... ok, it would break backwards compatibility, but how
>>many people are using this mechanism already?)

HH> hm, but as a heavy context user i count myself as 2048 users so ...

ROTFL :) OK, it's 2048 users to 2, but then again in how many
places do you make use of the multilocs being 1 when unsplit? :)

But then, a boolean could suffice; is there hope to see it in the
next beta?

-- 
Giuseppe "Oblomov" Bilotta

Re: Re[3]: Backgrounds

[John Culleton]

On Friday 11 April 2003 12:02 pm, Hans Hagen wrote:
>
> hm, but as a heavy context user i count myself as 2048 users so ...
>
> Hans

One time American President Abraham Lincoln proposed something and no one in
his cabinet favored it. He declared:

``The vote is one in favor, eleven against. The motion is
approved.''

So Hans can rely on presidential precedent :-)


John Culleton

supp-emp.tex \EMlinewd

[Hartmut Henkel]

The triangle on page 1 of supp-emp.tex gives an xpdf viewer error. The
triangle is drawn by

1 0 0 1 297.6378 162.1187 cm
0.4pt w 0 0 m -198.4247 56.69276 l S
   ^^
... (extracted by "pdftosrc supp-emp.pdf 15")

There a TeX "pt" sneaks into the width parameter. Somehow the
\edef\EMlinewd{\the\linewidth} seems to be used instead of the
\def\EMlinewd{.4}...

Greetings Hartmut

Re: supp-emp.tex \EMlinewd

[Hans Hagen]

At 01:06 14/04/2003 +0200, you wrote:
>The triangle on page 1 of supp-emp.tex gives an xpdf viewer error. The
>triangle is drawn by
>
>1 0 0 1 297.6378 162.1187 cm
>0.4pt w 0 0 m -198.4247 56.69276 l S
>    ^^
>... (extracted by "pdftosrc supp-emp.pdf 15")
>
>There a TeX "pt" sneaks into the width parameter. Somehow the
>\edef\EMlinewd{\the\linewidth} seems to be used instead of the

  ^^ just comment that line

it's the default (fall back) anyway

Hans

-------------------------------------------------------------------------
                                   Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                       Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
  tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------
                        information: http://www.pragma-ade.com/roadmap.pdf
                     documentation: http://www.pragma-ade.com/showcase.pdf
-------------------------------------------------------------------------

Re[4]: Backgrounds

[Giuseppe Bilotta]

Friday, April 11, 2003 Hans Hagen wrote:

HH> At 15:35 11/04/2003 +0200, Giuseppe Bilotta wrote:

>>I think I see; instead of drawing only the needed parts you draw
>>the whole frame and then cut the unwanted parts off. Is this more
>>efficient than drawing only the needed parts?

HH> simplier, less error prone, less code, more educative ...

Oh, BTW Hans, there are some visual differences between your code
and my code, which one notices as soon as the pen is changed (try
for example drawing your frames with a pen which is a pensquare
rotated 45).

Any news on the split boolean? :)

-- 
Giuseppe "Oblomov" Bilotta

Re[4]: Backgrounds

[Hans Hagen]

At 16:41 18/04/2003 +0200, you wrote:
>Friday, April 11, 2003 Hans Hagen wrote:
>
>HH> At 15:35 11/04/2003 +0200, Giuseppe Bilotta wrote:
>
> >>I think I see; instead of drawing only the needed parts you draw
> >>the whole frame and then cut the unwanted parts off. Is this more
> >>efficient than drawing only the needed parts?
>
>HH> simplier, less error prone, less code, more educative ...
>
>Oh, BTW Hans, there are some visual differences between your code
>and my code, which one notices as soon as the pen is changed (try
>for example drawing your frames with a pen which is a pensquare
>rotated 45).

indeed, i left that for you to do (not sure why you used a pensquare)

>Any news on the split boolean? :)

on the agenda; you have to ask n+1 times, with n->infinity, you know that, 
don't you?

(basically the bool could be a vardef: beginpage=endpage or so, have to 
look it up)

Hans
-------------------------------------------------------------------------
                                   Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                       Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
  tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------
                        information: http://www.pragma-ade.com/roadmap.pdf
                     documentation: http://www.pragma-ade.com/showcase.pdf
-------------------------------------------------------------------------

Re[5]: Backgrounds

[Giuseppe Bilotta]

Saturday, April 19, 2003 Hans Hagen wrote:
>>Oh, BTW Hans, there are some visual differences between your code
>>and my code, which one notices as soon as the pen is changed (try
>>for example drawing your frames with a pen which is a pensquare
>>rotated 45).

HH> indeed, i left that for you to do (not sure why you used a pensquare)

I used that shape because it gives a fancier border. "The clip
way" cancels some of the fancyness, even keeping the special pen
(e.g.: clipped instead of pointy endings.) Looks like I'll stay
with my definition :)

>>Any news on the split boolean? :)

HH> on the agenda; you have to ask n+1 times, with n->infinity, you know that,
HH> don't you?

HH> (basically the bool could be a vardef: beginpage=endpage or so, have to
HH> look it up)

Anything, as long as it allows the determination of the split
condition :)

-- 
Giuseppe "Oblomov" Bilotta

Re[5]: Backgrounds

[Hans Hagen]

At 14:10 19/04/2003 +0200, you wrote:
>Saturday, April 19, 2003 Hans Hagen wrote:
> >>Oh, BTW Hans, there are some visual differences between your code
> >>and my code, which one notices as soon as the pen is changed (try
> >>for example drawing your frames with a pen which is a pensquare
> >>rotated 45).
>
>HH> indeed, i left that for you to do (not sure why you used a pensquare)
>
>I used that shape because it gives a fancier border. "The clip
>way" cancels some of the fancyness, even keeping the special pen
>(e.g.: clipped instead of pointy endings.) Looks like I'll stay
>with my definition :)

or add:

   setbounds currentpicture to boundingbox currentpicture enlarged 1pt ;

Hans
-------------------------------------------------------------------------
                                   Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                       Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
  tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------
                        information: http://www.pragma-ade.com/roadmap.pdf
                     documentation: http://www.pragma-ade.com/showcase.pdf
-------------------------------------------------------------------------

Re[6]: Backgrounds

[Giuseppe Bilotta]

Monday, April 21, 2003 Hans Hagen wrote:
>>I used that shape because it gives a fancier border. "The clip
>>way" cancels some of the fancyness, even keeping the special pen
>>(e.g.: clipped instead of pointy endings.) Looks like I'll stay
>>with my definition :)

HH> or add:

HH>    setbounds currentpicture to boundingbox currentpicture enlarged 1pt ;

Still doesn't address the difference in the flat vs spiked ends of
the path.

-- 
Giuseppe "Oblomov" Bilotta

Error: /undefined in NP

[scarso luigi]

It seem to happen to gs (8.0 and 6.52) when I mix fonts from different
vendor,
for example when use serif and sans-serif  from Bitstream Humanist and
tt from Computer Modern.

Acroread and xpdf have no problem in rendering.

I don't found any useful information about it: any help ?

luigi

Re: Error: /undefined in NP

[scarso luigi]

Il mar, 2003-03-25 alle 19:00, scarso luigi ha scritto:
> It seem to happen to gs (8.0 and 6.52) when I mix fonts from different
> vendor,
> for example when use serif and sans-serif  from Bitstream Humanist and
> tt from Computer Modern.
> 
> Acroread and xpdf have no problem in rendering.
> 
> I don't found any useful information about it: any help ?
> 
A solution seem to be including all glyphs from a font
ie if texnansi-bitstrea-humanist.map contains the row
 texnansi-raw-hum521b Humanist521BT-Bold 4 < hum521b.pfb texnansi.enc
replace with 
 texnansi-raw-hum521b Humanist521BT-Bold 4 << hum521b.pfb texnansi.enc

Re: Error: /undefined in NP

[Jens-Uwe Morawski]

On 26 Mar 2003 13:55:23 +0100
scarso luigi <scarsoluigi@libero.it> wrote:

> Il mar, 2003-03-25 alle 19:00, scarso luigi ha scritto:
> > It seem to happen to gs (8.0 and 6.52) when I mix fonts from different
> > vendor,
> > for example when use serif and sans-serif  from Bitstream Humanist and
> > tt from Computer Modern.
> > 
> > Acroread and xpdf have no problem in rendering.
> > 
> > I don't found any useful information about it: any help ?
> > 
> A solution seem to be including all glyphs from a font
> ie if texnansi-bitstrea-humanist.map contains the row
>  texnansi-raw-hum521b Humanist521BT-Bold 4 < hum521b.pfb texnansi.enc
> replace with 
>  texnansi-raw-hum521b Humanist521BT-Bold 4 << hum521b.pfb texnansi.enc

the whole format looks very strange to me, what about

texnansi-raw-hum521b Humanist521BT-Bold "TeXnANSIEncoding ReEncodeFont" <texnansi.enc <hum521b.pfb 


Jens

Re: Error: /undefined in NP

[scarso luigi]

> the whole format looks very strange to me, what about
> 
> texnansi-raw-hum521b Humanist521BT-Bold "TeXnANSIEncoding ReEncodeFont" <texnansi.enc <hum521b.pfb 
> 
> 
> Jens


It's a line from file texnansi-bitstrea-humanist.map generated by texfont (texfont --help;
see also mtexfont.pdf, mfonts.pdf and pdftex-a.pdf)
This line say, among others, that only glyphs from font hum521b.pfb (a
Type1 font) used by  A.pdf document must be include into A.pdf (partial
inclusion).
Until now, I haven't found any problem with xpdf and acroread, but
postpocressing with gs sometimes fails, because some glyphs  seems to
call an instructions (NP) which definitions is not included.
Hence with
texnansi-raw-hum521b Humanist521BT-Bold "TeXnANSIEncoding ReEncodeFont"
<texnansi.enc <<hum521b.pfb 
we include all glyphs (complete inclusion), even unsed ones, and NP now
is not more undefined (for gs) 

By the way,if A.pdf has a partial inclusion and  we print on file A.ps
with acroread and then reconvert to A1.pdf with gs, A1.pdf semm to be ok
(but you loose interactivity)

I find at
http://www.tug.org/pipermail/pdftex/2002-October/003067.html
a mail about the same problems with pdflatex and I find the following
<<
"The PDF file is incorrect. It includes a subsed of /CharterBT-
Roman font that uses NP procedure but doesn't define it in
the font header."
>>

and in 
http://www.ghostscript.com/pipermail/gs-devel/2002-October/002043.html
I find the following
<<
#616539 - USER - gs fails for pdflatex generated document
assigned: alexcher
If a PDF document generated by pdflatex contains some special
combinations of 
type1 fonts, gs fails with "Error: /undefined in NP" while acroread and
xpdf have no problems to display the document. Alex determined that the
PDF file is invalid, and that it includes a subsed of /CharterBT-Roman
font that uses NP procedure but doesn't define it in the font header. 
Should we close the bug?
>>

I'm sure that it's not a complete explanations, but I have to study the
Adobe manual on Type1 fonts and encodings , and time is not on my
side....

luigi