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 o
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 - fpc-pascal@l
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 memor
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 16-b
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 gr
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], Length(Inp
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, TFPComp
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
> >> conversions)
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 eac
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 Pix
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 wi
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
sayi
13 matches
Mail list logo
