ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
* metafun color broken?
@ 2006-06-13 20:48 Hans van der Meer
       [not found] ` <6faad9f00606150852v11090646ga5a97227a8ab77bf@mail.gmail.com>
  0 siblings, 1 reply; 5+ messages in thread
From: Hans van der Meer @ 2006-06-13 20:48 UTC (permalink / raw)



[-- Attachment #1.1: Type: text/plain, Size: 594 bytes --]

I used to draw in transparent color in MetaFun with:

    newinternal tfill_mode; tfill_mode := 1;	% transparency mode for  
inside
    newinternal tfill_fact;	tfill_fact := 1;	% transparency factor  
for inside
    def withFillColor = withcolor transparent(tfill_mode, tfill_fact,  
fillcolor_) enddef;
    fill somepath withFillColor;

Suddenly (since the june update I guess) this fails.
Because

    fill somepath withcolor fillcolor_;

is still working I wonder if something has done to this transparency  
business.
If there was a change, why? It brings me trouble.

Hans van der Meer




[-- Attachment #1.2: Type: text/html, Size: 2910 bytes --]

[-- Attachment #2: Type: text/plain, Size: 139 bytes --]

_______________________________________________
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: metafun color broken?
       [not found] ` <6faad9f00606150852v11090646ga5a97227a8ab77bf@mail.gmail.com>
@ 2006-06-15 19:12   ` Hans van der Meer
  2006-06-15 19:50     ` Taco Hoekwater
  2006-06-15 21:07     ` Hans Hagen
  0 siblings, 2 replies; 5+ messages in thread
From: Hans van der Meer @ 2006-06-15 19:12 UTC (permalink / raw)
  Cc: NTG ConTeXt

After posting this problem I did probe a lot further in this and a  
similar problem.
As I reported shortly, the problem goes away when solely replacing in  
supp-mps.tex the line
\ifx\TEXEXECcommand \undefined \def\TEXEXECcommand{texmfstart  
texexec} \fi
by
\ifx\TEXEXECcommand \undefined \def\TEXEXECcommand{texexec} \fi
This gives me the impression it might not be in context itself,  
especially since to my (inexperienced) eye there are no or few  
changes between the working and nonworking versions that might  
explain the problem.
It might be the change from the perl to the ruby scripts with a  
problem in one of the latter.

I expect Hans or Taco to react soon with there usual speed and will  
await for their comments first.

Hans van der Meer


On Jun 15, 2006, at 17:52, Mojca Miklavec wrote:

> Replying off-list since I have no place to test anything and no  
> time righ now:
>
> I know that Hans has played with transparency at the beginning of May
> in order to enable it in XeTeX (but that should happen/break already
> earlier then), but I can't help you any further. Normar "with color
> transparent" worked a couple of days ago as far as I can remember, but
> I might have had an older version installed (from May).
>
>
> However: I would like to ask you to commit such examples (you have
> much more bug reports everywhere) to "contexttest" suite, see

I usually do this when in doubt if my code is right.
But in this case formerly perfectly working code is suddenly broken.
And of course I need to run my production and development runs on my  
own machine, so I have to solve it for that one.

> http://wiki.contextgarden.net/Test.
>
> Mojca
>
>
> On 6/13/06, Hans van der Meer  wrote:
>>
>> I used to draw in transparent color in MetaFun with:
>>
>>    newinternal tfill_mode; tfill_mode := 1; % transparency mode  
>> for inside
>>    newinternal tfill_fact; tfill_fact := 1; % transparency factor  
>> for inside
>>    def withFillColor = withcolor transparent(tfill_mode, tfill_fact,
>> fillcolor_) enddef;
>>    fill somepath withFillColor;
>>
>> Suddenly (since the june update I guess) this fails.
>> Because
>>
>>    fill somepath withcolor fillcolor_;
>>
>> is still working I wonder if something has done to this transparency
>> business.
>> If there was a change, why? It brings me trouble.
>>
>>
>> Hans van der Meer

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: metafun color broken?
  2006-06-15 19:12   ` Hans van der Meer
@ 2006-06-15 19:50     ` Taco Hoekwater
  2006-06-15 21:03       ` Hans Hagen
  2006-06-15 21:07     ` Hans Hagen
  1 sibling, 1 reply; 5+ messages in thread
From: Taco Hoekwater @ 2006-06-15 19:50 UTC (permalink / raw)
  Cc: Mojca Miklavec


Hi Hans,

Hans van der Meer wrote:
> 
> I expect Hans or Taco to react soon with there usual speed and will  
> await for their comments first.

Perhaps you missed the post below. The current problem is just
a different symptom of the same problem.

Greetings, Taco

Taco Hoekwater wrote:
 > Hans van der Meer wrote:
 >
 >> 2. The mpgraph.1 files differ only slightly, except for a few roundoff
 >> differences:
 >> new format extra lines: (but not a problem, I would guess)
 >> %%MetaPostSpecials: 2.0 123 1000
 >> %%HiResBoundingBox: -5.66927 -5.66927 359.9991 119.05481
 >> %%MetaPostSpecial: 7 1 1 1 1 0.94118 1 3
 >
 >
 > Believe it or not, but this is a known problem within web2c.
 > It is triggered by an interaction between the new texexec
 > and having two different entries in texmf.cnf for Metaposts
 > memory size, for example like this:
 >
 >   main_memory.mpost        = 500000
 >   main_memory.metafun      = 3000000
 >
 > Now, the metafun format is generated as "mpost", but the
 > graphics are created as "metafun", and the different memory
 > sizes make the specials go disappear.
 >
 > Strangely, I thought Hans and I had fixed by that a few weeks
 > back by changing the mpost commandlines, but apparently we didn't.
 >
 > A workaround (while we sort this out) is to make sure that the
 > .mpost and .metafun settings use the same (highest) number.
 >
 > Taco
 >

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: metafun color broken?
  2006-06-15 19:50     ` Taco Hoekwater
@ 2006-06-15 21:03       ` Hans Hagen
  0 siblings, 0 replies; 5+ messages in thread
From: Hans Hagen @ 2006-06-15 21:03 UTC (permalink / raw)
  Cc: Mojca Miklavec

Taco Hoekwater wrote:
> Hi Hans,
>
> Hans van der Meer wrote:
>   
>> I expect Hans or Taco to react soon with there usual speed and will  
>> await for their comments first.
>>     
>
> Perhaps you missed the post below. The current problem is just
> a different symptom of the same problem.
>   

part of the problem is that when no progname is given, the format should 
determine the progname (at least that was the case soem tiem ago) but 
then, mpost is behaving weird with respect to mem vars anyway; the 
current (context) approach is 'use metafun everywhere a prognam eis 
needed' [a problem, at least in the past, is that there were tetex 
versions with no metafun entries in texmf.cnf so we went back to mpost 
as progname for a while]

> Greetings, Taco
>
> Taco Hoekwater wrote:
>  > Hans van der Meer wrote:
>  >
>  >> 2. The mpgraph.1 files differ only slightly, except for a few roundoff
>  >> differences:
>  >> new format extra lines: (but not a problem, I would guess)
>  >> %%MetaPostSpecials: 2.0 123 1000
>  >> %%HiResBoundingBox: -5.66927 -5.66927 359.9991 119.05481
>  >> %%MetaPostSpecial: 7 1 1 1 1 0.94118 1 3
>  >
>  >
>  > Believe it or not, but this is a known problem within web2c.
>  > It is triggered by an interaction between the new texexec
>  > and having two different entries in texmf.cnf for Metaposts
>  > memory size, for example like this:
>  >
>  >   main_memory.mpost        = 500000
>  >   main_memory.metafun      = 3000000
>  >
>  > Now, the metafun format is generated as "mpost", but the
>  > graphics are created as "metafun", and the different memory
>  > sizes make the specials go disappear.
>  >
>  > Strangely, I thought Hans and I had fixed by that a few weeks
>  > back by changing the mpost commandlines, but apparently we didn't.
>  >
>  > A workaround (while we sort this out) is to make sure that the
>  > .mpost and .metafun settings use the same (highest) number.
>  >
>  > Taco
>  >
> _______________________________________________
> ntg-context mailing list
> ntg-context@ntg.nl
> http://www.ntg.nl/mailman/listinfo/ntg-context
>   


-- 

-----------------------------------------------------------------
                                          Hans Hagen | PRAGMA ADE
              Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
     tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
                                             | www.pragma-pod.nl
-----------------------------------------------------------------

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: metafun color broken?
  2006-06-15 19:12   ` Hans van der Meer
  2006-06-15 19:50     ` Taco Hoekwater
@ 2006-06-15 21:07     ` Hans Hagen
  1 sibling, 0 replies; 5+ messages in thread
From: Hans Hagen @ 2006-06-15 21:07 UTC (permalink / raw)
  Cc: Mojca Miklavec

Hans van der Meer wrote:
> I expect Hans or Taco to react soon with there usual speed and will  
> await for their comments first.
>   
as taco mentioned, it's in the mem values; mpost does not store them with the format (in the past this even could give segfaults and worse); tex does not have this problem 

Hans 


-----------------------------------------------------------------
                                          Hans Hagen | PRAGMA ADE
              Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
     tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
                                             | www.pragma-pod.nl
-----------------------------------------------------------------

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2006-06-15 21:07 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-06-13 20:48 metafun color broken? Hans van der Meer
     [not found] ` <6faad9f00606150852v11090646ga5a97227a8ab77bf@mail.gmail.com>
2006-06-15 19:12   ` Hans van der Meer
2006-06-15 19:50     ` Taco Hoekwater
2006-06-15 21:03       ` Hans Hagen
2006-06-15 21:07     ` Hans Hagen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).