I'm following the article below to install fpc in MascOSX (Sierra):
http://www.freepascal.org/~michael/articles/lazonmac/lazonmac.pdf
I managed to install gdb from macports.
The article points that to gdb work properly is necessary to edit
com.apple.taskgated.plist file
But in recent versions
Hello,
I've pushed an update to SVN for fcl-pdf.
The code can now do a partial embedding of a TTF font:
just the characters used in the PDF will be embedded.
This results in a much smaller PDF file.
Michael.
___
fpc-pascal maillist -
In our previous episode, Mattias Gaertner said:
> > Are there still no ways around the 64-bit storage format? I thought
> > TLazintfImage was meant to be a step in that direction?
>
> There are various image formats (TLazintfImage,
> TFPCompactImgRGBA8Bit, TFPCompactImgGrayAlpha8Bit, ..), so
Am 09.12.2016 10:05 schrieb "Graeme Geldenhuys" <
mailingli...@geldenhuys.co.uk>:
> The most widely used image editing software for X11 based
> systems, The GIMP, doesn't even support 16bit color channel images.
If I remember correctly the next major version of The GIMP is supposed to
support
On Fri, 9 Dec 2016, Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
Why FPImage uses 64bit per pixel is beyond me! The original author of
FPImage clearly thought he/she saw something cool in that, but 99.9%
of the time *nobody* needs that. It's causing more
On Fri, 9 Dec 2016, fredvs wrote:
Hello.
Thanks Michael for answer.
What happens with the buffer in which you had data, this we do not know.
Here is the schema of recording:
1) At creation:
DataRec := TMemoryStream.Create;
2 ) In loop:
...
DataRec.WriteBuffer(InputBuffer[0],
On Fri, 9 Dec 2016 12:39:54 +0100 (CET)
mar...@stack.nl (Marco van de Voort) wrote:
>[...]
> Are there still no ways around the 64-bit storage format? I thought
> TLazintfImage was meant to be a step in that direction?
There are various image formats (TLazintfImage,
TFPCompactImgRGBA8Bit,
In our previous episode, Michael Van Canneyt said:
> >> Why FPImage uses 64bit per pixel is beyond me! The original author of
> >> FPImage clearly thought he/she saw something cool in that, but 99.9%
> >> of the time *nobody* needs that. It's causing more grief (and code to do
> >>
Hello.
Thanks Michael for answer.
> What happens with the buffer in which you had data, this we do not know.
Here is the schema of recording:
1) At creation:
DataRec := TMemoryStream.Create;
2 ) In loop:
...
DataRec.WriteBuffer(InputBuffer[0], Length(InputBuffer)); // RAM used
increase at
On 2016-12-09 09:04, Graeme Geldenhuys wrote:
> What I'm
> saying is that FPImage uses 16bit color channels, but literally only a
> hand full (and I mean less than 5) of image editing programs support
> 16bit color channel images.
Impressively, the now discontinued cross-platform image editor
On 2016-12-09 09:14, Michael Van Canneyt wrote:
>
> The desire was to be able to support all possible channels when reading a
> file.
> That means 16bit.
OK, I can see the logic behind that. Time for another coffee, to kick
my brain into gear. ;-)
Regards,
Graeme
On Fri, 9 Dec 2016, Graeme Geldenhuys wrote:
On 2016-12-09 07:28, Michael Van Canneyt wrote:
The 64bit is the maximum limit. I doubt the 99.9%. Image editing
require more than 8bit per channel since decades.
And that is why we decided to use 64-bit.
Sorry, maybe I'm getting confused
On 2016-12-09 07:28, Michael Van Canneyt wrote:
>> > The 64bit is the maximum limit. I doubt the 99.9%. Image editing
>> > require more than 8bit per channel since decades.
> And that is why we decided to use 64-bit.
Sorry, maybe I'm getting confused with the meaning of all than. What I'm
13 matches
Mail list logo
