Re: [fpc-pascal] Printing TFPImage to TCairoPSCanvas

[Michael Van Canneyt]

On Mon, 21 May 2018, Leonardo M. Ramé via fpc-pascal wrote:



On Mon, 21 May 2018, Leonardo M. Ramé via fpc-pascal wrote:


Hi, I need to print an TFPMemoryimage into Printer.Canvas (which uses
TCairoPSCanvas to printing to CUPS) from a Linux CGI (no widgetset), but
it seems that it's an impossible task, because Printer.Canvas requieres a
TBitmap which in turn requires a widgetset.  Can anyone help me with
this?.

BTW, can fpReport print to a Printer? all the examples "exports" to PDF and 
other formats, but none of them is sending directly the report to a printer.



If you use the LCL, it uses the printer canvas.

A FPImage PostScript canvas exists, but it's largely untested. In theory,
this could be used to create a postscript file and that could be sent
directly to cups.

Michael.

Hi Michael, do you mean TPostscriptCanvas from PSCanvas.pp?, that doesn't seem 
to have a way to render a bitmap.


Yes, that is what I meant. It desperately awaits completion of course :(



I think I must send my bitmap to imagemagick's convert to create the Postscript 
file, then use lpr to send it to the printer.


That will be the easiest for the time being...

Michael.___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Printing TFPImage to TCairoPSCanvas

[Leonardo M . Ramé via fpc-pascal]

On Mon, 21 May 2018, Leonardo M. Ramé via fpc-pascal wrote:

> Hi, I need to print an TFPMemoryimage into Printer.Canvas (which uses
> TCairoPSCanvas to printing to CUPS) from a Linux CGI (no widgetset), but
> it seems that it's an impossible task, because Printer.Canvas requieres a
> TBitmap which in turn requires a widgetset.  Can anyone help me with
> this?.
>
> BTW, can fpReport print to a Printer? all the examples "exports" to PDF and 
> other formats, but none of them is sending directly the report to a printer.


If you use the LCL, it uses the printer canvas.

A FPImage PostScript canvas exists, but it's largely untested. In theory,
this could be used to create a postscript file and that could be sent
directly to cups.

Michael.

Hi Michael, do you mean TPostscriptCanvas from PSCanvas.pp?, that doesn't seem 
to have a way to render a bitmap.

I think I must send my bitmap to imagemagick's convert to create the Postscript 
file, then use lpr to send it to the printer.

Leonardo.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Printing TFPImage to TCairoPSCanvas

[Michael Van Canneyt]

On Mon, 21 May 2018, Leonardo M. Ramé via fpc-pascal wrote:


Hi, I need to print an TFPMemoryimage into Printer.Canvas (which uses
TCairoPSCanvas to printing to CUPS) from a Linux CGI (no widgetset), but
it seems that it's an impossible task, because Printer.Canvas requieres a
TBitmap which in turn requires a widgetset.  Can anyone help me with
this?.

BTW, can fpReport print to a Printer? all the examples "exports" to PDF and 
other formats, but none of them is sending directly the report to a printer.


If you use the LCL, it uses the printer canvas.

A FPImage PostScript canvas exists, but it's largely untested. In theory,
this could be used to create a postscript file and that could be sent
directly to cups.

Michael.___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Printing TFPImage to TCairoPSCanvas

[Leonardo M . Ramé via fpc-pascal]

Hi, I need to print an TFPMemoryimage into Printer.Canvas (which uses 
TCairoPSCanvas to printing to CUPS) from a Linux CGI (no widgetset), but it 
seems that it's an impossible task, because Printer.Canvas requieres a TBitmap 
which in turn requires a widgetset.
Can anyone help me with this?. 

BTW, can fpReport print to a Printer? all the examples "exports" to PDF and 
other formats, but none of them is sending directly the report to a printer.
Regards,Leonardo.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

[Maciej Izak]

2018-05-21 10:12 GMT+02:00 Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org>:
>
> That is at least what I would *expect* for Delphi as well. And no, I'm
> definitely not underestimating their ability to come up with strange
> syntaxes... Do I do prefer not to think about it too much to avoid
> nightmares :P
>

xD


> I've decided to lift the restriction again in r39078. Happy now?
>

I can't be fully happy because I am not part of FPC core anymore but for
sure I am more happy than before :)

-- 
Best regards,
Maciej Izak
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

[Maciej Izak]

2018-05-21 10:49 GMT+02:00 Jonas Maebe :

> Breaking backwards compatibility is one of the the worst things you can do
> in a programming language/compiler, and the primary concern when making
> changes to a language should always be to avoid this (except when you're
> developing a new language that's still in its infancy).
>
> Even if you design everything with that mindset, you know that you will
> still have to do it occasionally because you missed certain things or could
> not foresee them. Especially since no one cares to formally specify and
> analyse standards for Pascal anymore, so nothing gets vetted properly.
> Those cases are enough, there is no need to intentionally add more (even if
> only potential ones).
>
> Breaking backwards compatibility wastes time (both of the developer that
> has document the change and the users that have to adapt their —or worse,
> other people's— code), wastes energy on friction (users annoyed that their
> code no longer works, compiler developers annoyed that users didn't read
> the changelog, noise on fora/mailing lists, extra bug reports), and breaks
> the most fundamental expectation of using a high level language
> (unambiguous/formally correct code that used to compile/work should keep
> compiling/working; that's the whole point of using a high level language).
>
> Some of the above things can also happen if a particular feature is not
> available in a certain language mode, but that is bound to the nature of
> language modes: not all language modes provide the same features and/or
> features in the same way.


Generally I fully agree with that... Anyway Delphi mode/case is special.
AFAIK all significant Delphi compiler developers are lay off. The progress
for classic Delphi is almost dead and Delphi NEXTGEN totally breaks
backward compatibility.

We have interesting time : FPC Delphi mode with FPC RTL is more backward
compatible with Delphi than new Delphi :).

I don't like the totally prohibition for all new things in Delphi mode,
this is because not everyone is happy with ObjFPC and personally I prefer
more Delphi syntax (XE2 level/features) but I want to have new features too
(like fully working "Dynamic array extensions" without any prohibitions). I
like to use some elements from Oxygene dialect (which probably can not be
100% ported into FPC). I have many voices abut this from community and many
programmers agree with me.

The solution for keeping Delphi mode in right place and leave ObjFPC in FPC
core hands, is new mode : NewPascal.

This was discussed few years ago that I will be able to do new mode when I
will done few modeswitches, but now I am outside core team, situation is a
little complicated but I am more determined. :)

-- 
Best regards,
Maciej Izak
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

[Jonas Maebe]

On 21/05/18 01:36, Maciej Izak wrote:
IMO potentially breaking compatibility is better than lock/prohibition 
for missing features in Delphi (or waiting for Delphi implementation).


Breaking backwards compatibility is one of the the worst things you can 
do in a programming language/compiler, and the primary concern when 
making changes to a language should always be to avoid this (except when 
you're developing a new language that's still in its infancy).


Even if you design everything with that mindset, you know that you will 
still have to do it occasionally because you missed certain things or 
could not foresee them. Especially since no one cares to formally 
specify and analyse standards for Pascal anymore, so nothing gets vetted 
properly. Those cases are enough, there is no need to intentionally add 
more (even if only potential ones).


Breaking backwards compatibility wastes time (both of the developer that 
has document the change and the users that have to adapt their —or 
worse, other people's— code), wastes energy on friction (users annoyed 
that their code no longer works, compiler developers annoyed that users 
didn't read the changelog, noise on fora/mailing lists, extra bug 
reports), and breaks the most fundamental expectation of using a high 
level language (unambiguous/formally correct code that used to 
compile/work should keep compiling/working; that's the whole point of 
using a high level language).


Some of the above things can also happen if a particular feature is not 
available in a certain language mode, but that is bound to the nature of 
language modes: not all language modes provide the same features and/or 
features in the same way.



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

[Mark Morgan Lloyd]

On 20/05/18 12:30, Sven Barth via fpc-pascal wrote:


## "+" operator
The compiler now implements a "+" operator for arrays which is the same 
as if Concat() would be called on the arrays.
Note regarding backwards compatibility: existing "+" operator overloads 
for dynamic arrays no longer compile.


Does that only apply when both operands are compatible dynamic arrays, 
or does it also break definition of + to append an element to an array?


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Dynamic Array, operator +

[Sven Barth via fpc-pascal]

Am 20.05.2018 um 18:39 schrieb Mathias:


Mixing dynamic and static array does not work properly yet.



The "+" operator is currently not supposed to work for static arrays. 
Please report as a feature request.



var
  a, b, c: array of byte;
  d: array[0..2] of byte = (6, 7, 8);
begin

[snip]

  //  d := [5, 6, 7]; // geht nicht
end;

This is currently not supposed to work either. If you want that you can 
file a separate feature request report though that won't have a high 
priority.


Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

[Sven Barth via fpc-pascal]

Am 21.05.2018 um 01:36 schrieb Maciej Izak:
2018-05-21 0:52 GMT+02:00 Sven Barth via fpc-pascal 
>:


The thing is that I can easily imagine the Delphi devs to be so
stoned to use the "[...]" for static arrays inside dynamic arrays
as well which could lead to constructs like the following because
they forget that dynamic arrays could be part of static arrays as
well:

=== code begin ===

var
  v: array[0..2] of array of array[0..2] of LongInt = ([[1, 2, 3],
[4, 5, 6]], [], [[7, 8, 9]]);

=== code end ===

Yes, I have absolutely no confidence in the Delphi developers.


Sometimes they have fantasy ^^. Don't underestimate them, I am sure 
they can do something more unexpected ;) For NewPascal mode I see this 
like :


var
  v: array[0..2] of array of array[0..2] of LongInt = ([(1, 2, 3), (4, 
5, 6)], [], [(7, 8, 9)]);


That is at least what I would *expect* for Delphi as well. And no, I'm 
definitely not underestimating their ability to come up with strange 
syntaxes... Do I do prefer not to think about it too much to avoid 
nightmares :P



I don't want to use a modeswitch for every tiny little bit of
feature. What we could do however would be a modeswitch for a
strict Delphi mode that prohibits extensions and code that does
not work in Delphi (like global operators and global generic
functions). This could be used for code that is shared with Delphi
to avoid potentially breaking compilability with Delphi if one is
mainly using FPC for testing.


IMO potentially breaking compatibility is better than lock/prohibition 
for missing features in Delphi (or waiting for Delphi implementation). 
Programmers are not stupid and most of Delphi users knows what Delphi 
have and what can be potentially risky. We have tons of examples which 
should be disabled in Delphi mode but it works for comfort. r39045 is 
for sure not comfortable IMO without real important reason, but this 
is just my opinion.


I've decided to lift the restriction again in r39078. Happy now?

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Dynamic Array, operator +

[Mathias]

Mixing dynamic and static array does not work properly yet.

I compiled the following code with the latest trunk of FPC (revision 39062):


procedure Ausgabe(a: array of byte);
var
  i: integer;
begin
  for i := 0 to Length(a) - 1 do begin
    Write(a[i]: 4);
  end;
  WriteLn();
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  a, b, c: array of byte;
  d: array[0..2] of byte = (6, 7, 8);
begin
  a := [1, 2, 3];
  Ausgabe(a);   // io.

  b := a + d + [123, 222];
  Ausgabe(b);   // error  --> Output:  1   2   3 123 222 123 222

  b := a + [123, 222];
  c := b + b;
  Ausgabe(c);   // io.
  Delete(c, 2, 2);
  Ausgabe(c);   // io.

  c := Concat(a, d, a); // io.
  Ausgabe(c);

  c := a + d + a;   // io.
  Ausgabe(c);


  //  d := [5, 6, 7]; // geht nicht
end;

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal