> On 6 Feb 2010, at 17:55, Albrecht Schlosser wrote:
>> Linux/Unix support: what should be done?
>
imacarthur wrote:
> I suppose, when it comes down to it, Mike is *the* linux printing
> guy... If he is around, he might have some ideas we could try?
Indeed..!
I know nothing abo
> For complete PS
> output we would probably need full postscript device support, but that
> might be tricky and maybe only doable with FLTK's (planned) device
> separation - that might be far in the future(?).
Can anybody give me a pointer to what is this "device separation" ?
__
manolo gouy wrote:
>> For complete PS
>> output we would probably need full postscript device support, but that
>> might be tricky and maybe only doable with FLTK's (planned) device
>> separation - that might be far in the future(?).
>
> Can anybody give me a pointer to what is this "device separa
On 7 Feb 2010, at 9:28, Albrecht Schlosser wrote:
>
> Anyway: the problem with using vector drawing, filling, etc.
> with PostScript would be to redirect all drawing functions
> to the PostScript device (driver) and to implement a full set
> of drawing primitives, together with all that is needed
>
> Currently not working in my test: Transparency (real alpha or
> transparent
> pixels like in Fl_Pixmap). I didn't test real alpha channel images yet.
> Is there a chance that transparency can work with printing devices?
>
> I'll post my demo program that shows the effect with a pixmap.
Albrec
manolo gouy wrote:
>> Currently not working in my test: Transparency (real alpha or
>> transparent
>> pixels like in Fl_Pixmap). I didn't test real alpha channel images yet.
>> Is there a chance that transparency can work with printing devices?
>>
>> I'll post my demo program that shows the effect
manolo gouy wrote:
> Albrecht: I have here a little lift to give to your morale :=)
Thanks, but my morale is okay. ;-)
> The print demo no longer loose widgets, because
> I removed a clip to window that works well (and is useful) under Mac
> but made all these widgets disappear in the print demo
manolo gouy wrote:
> Thanks Albrecht, your idea of placing the traverse call earlier
> indeed saves an offset calculation that was effectively done twice.
> I have further improved that by putting the traverse call after
> the fl_pop_clip() call, so we have no deeper clip stack cost
> (when the su
> I could only do a quick first test, and I had problems compiling on
> Windows (I had to remove Fl_Quartz_Printer.mm and .o from src/Makefile).
> We must find a way to fix this w/o the need to use ObjC on Windows (and
> Linux). But the new make rule is a good step forward, anyway.
That's repaire
On 27.02.2010, at 16:04, manolo gouy wrote:
>> To Matt: the fluid/image code will probably not help much, because it
>> renders the image into an Fl_Offscreen first, and that's what we don't
>> want to do here. At least not with the device abstraction in place.
>
> What would be needed is help t
Am 27.02.2010 10:46, manolo gouy wrote:
> Introduced in FLTK-Fl_Printer branch device abstraction and PostScript
> output
> using Roman's ideas and code.
> Many thanks to Roman!
Manolo, just to be sure: did you take the code from FLTK 1.2, as
Roman suggested? I can't really diff the new code and
>
> After fixing a couple of minor compilation problems, I can now print
> successfully on Windows, but there's a small problem with PS output on
> Linux: I had to change
>
> %%BeginFeature: *PageSize
> -A4
> +%% A4
> %%EndFeature
>
> in the prolog, because PS interpretation showed an error messa
Am 28.02.2010 12:55, manolo gouy wrote:
>>
>> After fixing a couple of minor compilation problems, I can now print
>> successfully on Windows, but there's a small problem with PS output on
>> Linux: I had to change
>>
>> %%BeginFeature: *PageSize
>> -A4
>> +%% A4
>> %%EndFeature
>>
>> in the pr
> I have also (boldly) added a new configuration called DebugX11
> that allows to build an X11-based FLTK-1.3-Fl_Printer on Mac OS X,
> and thus to test the Linux/Unix side of FLTK (remember that Mac OS X
> is on top of unix). All libraries and demos should readily compile,
> and they should also
On 02.03.2010, at 14:23, MacArthur, Ian (SELEX GALILEO, UK) wrote:
>
>> I have also (boldly) added a new configuration called DebugX11
>> that allows to build an X11-based FLTK-1.3-Fl_Printer on Mac OS X,
>> and thus to test the Linux/Unix side of FLTK (remember that Mac OS X
>> is on top of uni
Matthias Melcher wrote:
> Event better (but now I am going crazy ;-) would be to use the new Fl_Device
> to allow Cocoa *and* X11 from within the same application. A user could
> decide at run-time if the app is running locally or on a remote X11 client
> (or Cairo or VNC for that matter).
No,
16 matches
Mail list logo
