Re: [Lazarus] PDF generator: please test

[Ondrej Pokorny]

You've got a bug in the font height functions. They must not be scaled 
with ToNatural.


Try e.g. the Tahoma font from Windows or any other font where 
FHead.UnitsPerEm<>1000. You'll see wrong results.


Your example works because FHead.UnitsPerEm is 1000 for your version of 
FreeSans. If you use an old FreeSans where UnitsPerEm is 2048, you get 
wrong box height.


I needed about 2 hours to find it :(

See http://mantis.freepascal.org/view.php?id=30008

Ondrej

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

[Lazarus] [ANN] New PostgreSQL diff tool (Lazarus + Zeos)

[Alexsander Rosa]

https://github.com/rednaxelbr/rnx-pgdiff

-- 
Atenciosamente,
Alexsander da Rosa
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] fpPDF: cannot embed DejaVu font

[José Mejuto]

El 13/04/2016 a las 14:52, Michael Van Canneyt escribió:


You must add images manually in a list.
Drawing an image means: "draw image N here at (X,Y)"
It is up to you to add an image only once and re-use that.


Hello,

Great, this answer my question completly! :)


--


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] fpPDF: cannot embed DejaVu font

[Michael Van Canneyt]

On Wed, 13 Apr 2016, Ondrej Pokorny wrote:


On 13.04.2016 18:06, Michael Van Canneyt wrote:



On Wed, 13 Apr 2016, Ondrej Pokorny wrote:


On 13.04.2016 17:52, Michael Van Canneyt wrote:


I prefer more options, it gives more fine-grained control.

We can make a
  CompressAll = [poCompressText, poCompressFonts, poCompressImages];
constant if you want, which will be kept up-to-date with all compression
options.


No, not needed. As I said, it's not that important.

Still could you please use poUseRawJPEG by default in TPDFDocument.Create? 
IMO poUseRawJPEG is very useful - it reduces both processing time because 
JPEG images don't have to be resampled by fpPDF and also keeps the 
exported PDF small.


I prefer not to, because of several reasons:
- it depends on 3.1 features.


No. In 3.1 the size detection is just faster/better.


Yes. 
So in 3.0 there is no time gain. You read the image anyway.

The detection works by reading the whole image, because it needs the size.




- It forces the examination of all added images.
  Examining is a waste of time for me, since I do not use JPEG, only PNG.


No. The only check it does more is "Handler.InheritsFrom(TFPReaderJPEG)". I 
don't think it is that time-consuming.


If you know you will have JPEG, you can use the JPEG function.




In each case, for an advanced user as you, I would expect that the first
thing you do is create a TOndrejPDFDocument subclass (or whatever the 
name). You can set all options there to defaults that you like. (I subclass 
all components I use for exactly such reasons)


Of course enabling it for myself isn't a problem. The problem is that I don't 
see any advantage disabling poUseRawJPEG and enabling poCompressImages by 
default - there is no :)


Sure. When 3.0.4 is out, then we can switch the default.

Michael.

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] fpPDF: set clip rect for text

[Ondrej Pokorny]

On 13.04.2016 19:44, Graeme Geldenhuys wrote:

On 2016-04-13 18:14, Ondrej Pokorny wrote:

TextWidth is already in fpTTF / TFPFontCacheItem.

Yes, but that one only handles TTF fonts that the fontcache found. In
fpReport I needed to handle Std PDF fonts too - hence I have separate
implementations for TextWidth() and TextHeight().


Reading your previous email, my opinion is that TextWidth() and 
TextHeight() (and other similar functions) should be supported only by 
fonts that the fontcache found.


If the programmer needs TTF functions on default PDF fonts, he has to 
make sure the TTF files are available. Easy as that :)


Ondrej

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] fpPDF: set clip rect for text

[Graeme Geldenhuys]

On 2016-04-13 18:14, Ondrej Pokorny wrote:
> 
> TextWidth is already in fpTTF / TFPFontCacheItem.

Yes, but that one only handles TTF fonts that the fontcache found. In
fpReport I needed to handle Std PDF fonts too - hence I have separate
implementations for TextWidth() and TextHeight().


> Actually, IMO it should be the programmers responsibility to include TTF 
> files for default PDF fonts if he wants to use TTF features on them.

True. But not just that. The PDF specification document actually
mentions that it is recommended to embed the standard fonts too. The
reason being, it is up to the PDF Viewer to find a similar font as
Helvetica, Times Roman etc and then use that. This in theory could give
you inaccurate PDF rendering results as not all copies of Helvetica,
Times Roman etc are equal on the various platforms. Unfortunately not
many seem to do this, as everybody likes the small file sizes. ;-)

My recommendation. Don't use the standard PDF fonts at all. From a
typography point of view, they are boring and ugly.


> +  For now fpPDF can render only ASCII glyphs for standard fonts. Is 
> this a limitation of the PDF format?

I'm not actually 100% sure of that. I think so.


>> There is similar functionality in fpReport. I'll see if we can move some
>> of that to fpPDF.
> 
> fpTTF is better, IMO. It should be made on TTF-level, not PDF.

You are correct.


Regards,
  Graeme

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] fpPDF: set clip rect for text

[Ondrej Pokorny]

On 13.04.2016 19:00, Graeme Geldenhuys wrote:

IMO multi-line text support should be added into TFPFontCacheItem.
>Something like:

My only problem with that, and why TextHeight() and TextWidth() is not
yet in fpTTF.pas unit, is the 14 PDF built-in fonts. The fontcache might
not have actual TTF files for say Helvetica, Times-Roman etc, but you
are still allowed to use those in your PDF.


TextWidth is already in fpTTF / TFPFontCacheItem.

Actually, IMO it should be the programmers responsibility to include TTF 
files for default PDF fonts if he wants to use TTF features on them. And 
your problem is solved :)


+  For now fpPDF can render only ASCII glyphs for standard fonts. Is 
this a limitation of the PDF format? If yes, then the default PDF fonts 
have to be embedded as TTF anyway in many cases anyway.



>Do you have some function like this in fpReport? Could it be extracted
>from fpReport into fpTTF? Or should I create one for myself?

There is similar functionality in fpReport. I'll see if we can move some
of that to fpPDF.


fpTTF is better, IMO. It should be made on TTF-level, not PDF.
It would be great if you could move it to fpTTF - it would spare me some 
time for other things. Although it shouldn't be that hard, but it's 
still a plus :)


Ondrej

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] fpPDF: set clip rect for text

[Graeme Geldenhuys]

On 2016-04-13 17:36, Ondrej Pokorny wrote:
> 
> I have no idea about graphics state :)

PDF does it all for you really. The idea is that you ask PDF to save the
current graphics state, apply your clip region, do your drawing or text
output, then ask PDF to restore the graphics state (thus remove your
clip region). Trick is just to know where to use the "q" and "Q"
PDF commands.


> Clipping and multi-line text are probably the last 2 features I miss.

So we are getting there. ;-)


> IMO multi-line text support should be added into TFPFontCacheItem. 
> Something like:

My only problem with that, and why TextHeight() and TextWidth() is not
yet in fpTTF.pas unit, is the 14 PDF built-in fonts. The fontcache might
not have actual TTF files for say Helvetica, Times-Roman etc, but you
are still allowed to use those in your PDF.

In fpReport I had to generate metric equivalent data (stored in an
include file) for all 14 PDF built-in fonts. So TextHeight() and
TextWidth() needs to first query if the font in question is a Std PDF
Font or not, then it knows to go to the fontcache or to the lookup
tables for glyph metric information.

I still need to figure out how to get this cleanly into fpTTF.pas. Part
of it (eg: is the font a Std PDF built-in or not) can possibly go into
fpPDF, the rest needs to go into fpTTF.pas.  But then my other issue
with that is that then fpTTF will depend on fpPDF and vice versa. I want
to keep dependencies to a minimum. Hence my struggle. :)


> Do you have some function like this in fpReport? Could it be extracted 
> from fpReport into fpTTF? Or should I create one for myself?

There is similar functionality in fpReport. I'll see if we can move some
of that to fpPDF.


Regards,
  Graeme

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] fpPDF: set clip rect for text

[Ondrej Pokorny]

On 13.04.2016 11:33, Graeme Geldenhuys wrote:

No, I haven't done any work on using the clipping operators yet. In
fpReport, text is rather wrapped than clipped.

Contributions in this regard are obviously very welcome. I would imagine
if the clipping operators are to be implemented, then graphics state
(save & restore) would probably go hand-in-hand with the clipping too.


I have no idea about graphics state :)

Clipping and multi-line text are probably the last 2 features I miss.

IMO multi-line text support should be added into TFPFontCacheItem. 
Something like:


TFPFontCacheItem.CalcMultiLineText(const AText: string; const AWidth, 
ALineHeight: single; const AAlignment: TTextAlignment): TMultiLineText;


TTextTag = record
  X, Y: Single;
  Text: string;
end;

TMultiLineText = record
  TextTags: array of TTextTag;
end;

The CalcMultiLineText would then calculate the X/Y-position of 
lines/tags (if justify alignment should be supported.) Then one could 
easily either draw it on PDF page or TCanvas.


Do you have some function like this in fpReport? Could it be extracted 
from fpReport into fpTTF? Or should I create one for myself?


Ondrej

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] fpTTF: TFPFontCacheItem properties aren't loaded from font

[Ondrej Pokorny]

On 13.04.2016 18:30, Graeme Geldenhuys wrote:

But you are welcome to make the changes you suggested above.


Good, I'll do it!

Ondrej

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] fpTTF: TFPFontCacheItem properties aren't loaded from font

[Graeme Geldenhuys]

On 2016-04-13 17:02, Ondrej Pokorny wrote:
> Can a TTF file embed font with various styles?

No, not that I'm aware of. Each style is a different TTF file.


> IMO the file should be read in TFPFontCacheItem.Create and the 
> properties should be set accordingly. Furthermore the properties should 
> be read-only as well.

You are correct on both counts. You are welcome to make that change.


On a side note:
  My initial thinking was that the TFPContCacheItem could manage
multiple TTF files of the same FamilyName. eg: Ubuntu-Regular.ttf,
Ubuntu-Bold.ttf, Ubuntu-Italic.ttf etc. The FamilyName would be
"Ubuntu". This thinking came from how fpGUI manages fonts. eg:
Label1.FontDesc = 'Ubuntu-13:bold,italic'; My thinking was that fpReport
could use similar. Internally the fontcache would know exactly which TTF
file to use. I found some problem with that idea (unfortunately I can't
remember what that was), and stopped work in that direction - until a
later date.

But you are welcome to make the changes you suggested above. I will take
up my research on fontcache mods some time in the future. I don't have
time at the moment.


Regards,
  — Graeme —

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] fpPDF: cannot embed DejaVu font

[Ondrej Pokorny]

On 13.04.2016 18:06, Michael Van Canneyt wrote:



On Wed, 13 Apr 2016, Ondrej Pokorny wrote:


On 13.04.2016 17:52, Michael Van Canneyt wrote:


I prefer more options, it gives more fine-grained control.

We can make a
  CompressAll = [poCompressText, poCompressFonts, poCompressImages];
constant if you want, which will be kept up-to-date with all 
compression

options.


No, not needed. As I said, it's not that important.

Still could you please use poUseRawJPEG by default in 
TPDFDocument.Create? IMO poUseRawJPEG is very useful - it reduces 
both processing time because JPEG images don't have to be resampled 
by fpPDF and also keeps the exported PDF small.


I prefer not to, because of several reasons:
- it depends on 3.1 features.


No. In 3.1 the size detection is just faster/better.


- It forces the examination of all added images.
  Examining is a waste of time for me, since I do not use JPEG, only PNG.


No. The only check it does more is 
"Handler.InheritsFrom(TFPReaderJPEG)". I don't think it is that 
time-consuming.
If you disable poUseRawJPEG and you feed fpPDF with a JPEG image, it 
actually wastes time and resources to resample/resave(/+recompress if 
poCompressImages is enabled) the image.




In each case, for an advanced user as you, I would expect that the first
thing you do is create a TOndrejPDFDocument subclass (or whatever the 
name). You can set all options there to defaults that you like. (I 
subclass all components I use for exactly such reasons)


Of course enabling it for myself isn't a problem. The problem is that I 
don't see any advantage disabling poUseRawJPEG and enabling 
poCompressImages by default - there is no :)


Ondrej

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] fpPDF: cannot embed DejaVu font

[Michael Van Canneyt]

On Wed, 13 Apr 2016, Ondrej Pokorny wrote:


On 13.04.2016 17:52, Michael Van Canneyt wrote:


I prefer more options, it gives more fine-grained control.

We can make a
  CompressAll = [poCompressText, poCompressFonts, poCompressImages];
constant if you want, which will be kept up-to-date with all compression
options.


No, not needed. As I said, it's not that important.

Still could you please use poUseRawJPEG by default in TPDFDocument.Create? 
IMO poUseRawJPEG is very useful - it reduces both processing time because 
JPEG images don't have to be resampled by fpPDF and also keeps the exported 
PDF small.


I prefer not to, because of several reasons:
- it depends on 3.1 features.
- It forces the examination of all added images.
  Examining is a waste of time for me, since I do not use JPEG, only PNG.
- I want the user to know and understand what he is doing.
  You do, but most will not (or so I think at first sight).
  By forcing them to enable some options, they will at least think about it.
  (or so I hope ;) )

In each case, for an advanced user as you, I would expect that the first
thing you do is create a TOndrejPDFDocument subclass (or whatever the name). 
You can set all options there to defaults that you like. 
(I subclass all components I use for exactly such reasons)


Michael.

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

[Lazarus] fpTTF: TFPFontCacheItem properties aren't loaded from font

[Ondrej Pokorny]

TFPFontCacheItem properties (FamilyName, IsBold, IsItalic, ...) aren't 
loaded from the font file. I have to assign them explicitely. Is it 
really wanted? Can a TTF file embed font with various styles?


E.g. I have to do now:

  TPrintFontCacheList = class(TFPFontCacheList)
  public
function Add(const AObject: TFPFontCacheItem): Integer;
  end;

function TPrintFontCacheList.Add(const AObject: TFPFontCacheItem): Integer;
begin
  Result := inherited Add(AObject);
  AObject.FamilyName := AObject.GetFontData.FamilyName;
  AObject.IsBold := AObject.GetFontData.Bold;
  AObject.IsItalic := AObject.GetFontData.ItalicAngle <> 0;
end;

in order the used font is correctly found.

IMO the file should be read in TFPFontCacheItem.Create and the 
properties should be set accordingly. Furthermore the properties should 
be read-only as well.


Ondrej

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] fpPDF: cannot embed DejaVu font

[Ondrej Pokorny]

On 13.04.2016 17:52, Michael Van Canneyt wrote:


I prefer more options, it gives more fine-grained control.

We can make a
  CompressAll = [poCompressText, poCompressFonts, poCompressImages];
constant if you want, which will be kept up-to-date with all compression
options.


No, not needed. As I said, it's not that important.

Still could you please use poUseRawJPEG by default in 
TPDFDocument.Create? IMO poUseRawJPEG is very useful - it reduces both 
processing time because JPEG images don't have to be resampled by fpPDF 
and also keeps the exported PDF small.


Ondrej

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] fpPDF: cannot embed DejaVu font

[Michael Van Canneyt]

On Wed, 13 Apr 2016, Ondrej Pokorny wrote:


On 13.04.2016 13:42, Michael Van Canneyt wrote:

The support for compressed images and embedding of raw JPEG is in SVN too,
sample program adapted to demonstrate this (-i -j command line options).


Thank you very much!

Just 2 points:

1.) Is the "Writeln('Compressing : ',poCompressImages in Owner.Options);" 
line wanted/necessary? Maybe you forgot {$ifdef gdebug}?


I will look at it ASAP.



2.) Don't we have too much TPDFOptions for compressing? In the future raw PNG 
embedding may be added and thus poUseRawPNG will be added (?). Maybe 
poUseRawJPEG can be omitted and replaced by poCompressImages?


No, they do different things.

Also 3 options for compressing "poCompressText, poCompressFonts, 
poCompressImages" seem to be useless for me. I either want to compress 
everything to get a small file or compress nothing to get a fast file.


I prefer more options, it gives more fine-grained control.

We can make a
  CompressAll = [poCompressText, poCompressFonts, poCompressImages];
constant if you want, which will be kept up-to-date with all compression
options.

Michael.

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] fpPDF: cannot embed DejaVu font

[Ondrej Pokorny]

On 13.04.2016 13:42, Michael Van Canneyt wrote:
The support for compressed images and embedding of raw JPEG is in SVN 
too,

sample program adapted to demonstrate this (-i -j command line options).


Thank you very much!

Just 2 points:

1.) Is the "Writeln('Compressing : ',poCompressImages in 
Owner.Options);" line wanted/necessary? Maybe you forgot {$ifdef gdebug}?


2.) Don't we have too much TPDFOptions for compressing? In the future 
raw PNG embedding may be added and thus poUseRawPNG will be added (?). 
Maybe poUseRawJPEG can be omitted and replaced by poCompressImages?


Also 3 options for compressing "poCompressText, poCompressFonts, 
poCompressImages" seem to be useless for me. I either want to compress 
everything to get a small file or compress nothing to get a fast file.


Maybe one poCompress would suffice for all 4 (poCompressText, 
poCompressFonts, poCompressImages, poUseRawPNG)?


(Just a suggestion, feel free to refuse it, it's not that important anyway.)

Ondrej

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Lazarus Digest, Vol 99, Issue 32

[Salvatore Coppola]

2016-04-09 12:20 GMT+02:00 Giuliano Colla :

> Il 08/04/2016 21:13, Juha Manninen ha scritto:
>
>> Welcome to open source.
>> Instead of complaining here and wasting everybody's time, you could
>> have improved the documentation yourself and provide a patch.
>>
>
> In principle you're right. However you should take into account some other
> factors.
>
> Frequently users do complain when a problem arises which they are unable
> to solve by themselves.
>
> Asking them to provide a patch doesn't help too much.


Sorry to reply so late but here you have hit the core of the question. Many
times I've tried to do something that failed in a miserable way (i.e.
miserable/hobbist/old programmer). BTW, contribute to an open source
project can be done as programmer, tester, artist, disigner, marketter etc.
So if someone has a good idea to improve the project but is not able to
implement it, I think there is nothing wrong with proposing it here without
this being interpreted as a request that the core developers must do. If
anyone knows how to do it, and overall want to do it, well, otherwise it
goes on and nothing changes. Anyway I want to say thanks to all of you, old
and new developers
Salvatore


> Giuliano
>
>
>
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus.freepascal.org
> http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
>
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] fpPDF: cannot embed DejaVu font

[Michael Van Canneyt]

On Wed, 13 Apr 2016, José Mejuto wrote:


El 13/04/2016 a las 13:42, Michael Van Canneyt escribió:


The support for compressed images and embedding of raw JPEG is in SVN too,
sample program adapted to demonstrate this (-i -j command line options).



Hello,

Does the library detect the same image used multiple times ?


You must add images manually in a list.
Drawing an image means: "draw image N here at (X,Y)"
It is up to you to add an image only once and re-use that.

In the past I 
was using a pdf generator for a report that has an image as background 
watermark. The report could be more than 100 pages and the pdf was 
multi-megabyte because the library adds each page watermark as a new graphic 
object, instead reuse the same object.


The fpreport engine will add the image only once and will reuse it.

Michael.--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] FLC-PDF and LazReport

[Michael Van Canneyt]

On Wed, 13 Apr 2016, Michael W. Vogel wrote:


Am 08.04.2016 um 23:40 schrieb Graeme Geldenhuys:


I've written a PDF export filter, using fcl-pdf, for the fpReport (Free
Pascal Reporting) project that will be released some time this year.
fpReport still needs to bake a bit longer. ;-)  There are more features
coming in fpPDF too.

Regards,
   - Graeme -

Very interesting!

Could you say something about fpReport? Is it a choice for LazReport or what 
is it for? Does it becomes part of FPC?


It becomes part of FPC. It is a banded reporting engine that does not depend
on any GUI widgetset. It needs to be usable in a headless webserver.

The feature set is roughly the one of Lazreport, but of course other 
enhancements
are planned. 
The fact that it is unit tested should already be an enhancement by itself :)


It will use a JSON file as input (or you can build it in code entirely), 
and will create various kinds of output, where initially we will make a 
PDF output engine.


We have already succesfully created test PDFs based on the engine, but we are
waiting to commit this to FPC till the first production reports are ready.

Currently there is no GUI designer yet, but this is planned; I think that
creating a designer should not be a big problem given the RTTI controls that
exist in Lazarus.

Michael.

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] fpPDF: cannot embed DejaVu font

[José Mejuto]

El 13/04/2016 a las 13:42, Michael Van Canneyt escribió:


The support for compressed images and embedding of raw JPEG is in SVN too,
sample program adapted to demonstrate this (-i -j command line options).



Hello,

Does the library detect the same image used multiple times ? In the past 
I was using a pdf generator for a report that has an image as background 
watermark. The report could be more than 100 pages and the pdf was 
multi-megabyte because the library adds each page watermark as a new 
graphic object, instead reuse the same object.


If its not easy to do automagically maybe an API to add a "shared" media 
object would be useful.


Thank you.


--


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] FLC-PDF and LazReport

[Michael W. Vogel]

Am 08.04.2016 um 23:40 schrieb Graeme Geldenhuys:


I've written a PDF export filter, using fcl-pdf, for the fpReport (Free
Pascal Reporting) project that will be released some time this year.
fpReport still needs to bake a bit longer. ;-)  There are more features
coming in fpPDF too.

Regards,
   - Graeme -

Very interesting!

Could you say something about fpReport? Is it a choice for LazReport or 
what is it for? Does it becomes part of FPC?


Kind regards

Michl

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] wiki page "Better_Unicode_Support_in_Lazarus"

[Michael Schnell]

On 04/13/2016 01:41 PM, Mattias Gaertner wrote:

Why do you think that?
If that would be the way the function StringCodePage would need to check 
if the encodeing imposed on the string (e.g. a String constant) (i.e. 
the final meaning of CP_ACP) would be the same as the value of the 
variable DefaultSystemCodePage which has been set at this start of the 
program.


I looked at the code of StringCodePage, and it does not do so.

-Michael

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] FLC-PDF and LazReport

[Michael W. Vogel]

Am 09.04.2016 um 02:08 schrieb Jesus Reyes A.:

But if somebody is in a hurry and wants to jump in, please say so.
I'm not really in hurry but it would be nice, not to ship all the dll 
(libcairo) with my app.


I found some time and made some first tests. I successfully created a 
first basic TlrFpPdfExportFilter. I think it is doable, but it will take 
some time. I will ask here if I have questions.


Thanks

Kind regards

Michl

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] fpPDF: cannot embed DejaVu font

[Michael Van Canneyt]

On Wed, 13 Apr 2016, Graeme Geldenhuys wrote:


On 2016-04-13 10:54, Ondrej Pokorny wrote:

Am I doing something wrong or is this a bug in fpPDF?


It's a bug. The BaseFont, FontName and FontFamily names (in fact any
PDFName elemens) may not contain spaces and should be escaped (or
encoded). I've fixed it locally, and the patch should be in FPC
hopefully some time today.

Thanks for reporting the issue.


Patch is in FPC svn: rev 33495.

The support for compressed images and embedding of raw JPEG is in SVN too,
sample program adapted to demonstrate this (-i -j command line options).

Michael.

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] wiki page "Better_Unicode_Support_in_Lazarus"

[Mattias Gaertner]

On Wed, 13 Apr 2016 12:53:49 +0200
Michael Schnell  wrote:

> On 04/13/2016 11:08 AM, Sven Barth wrote:
> >
> > The code pages that are relevant here are only single byte code pages 
> > (e.g. CP1252) or UTF-8, *never* UTF-16 as a AnsiString can not store 
> > UTF-16 data.
> >
> 
> StringCodePage(s) with an unqualified String return 0 (which is 
> "CP_ACP", and seemingly means "Default").

It means DefaultSystemCodePage.

> But how to determine what encoding this default is, if (as we found) it 
> can't be DefaultSystemCodePage and can be UTF16,

Why do you think that?

> which is dynamic, while 
> the default for unqualified strings is static and *never* UTF-16 ?


Mattias

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] fpPDF: set clip rect for text

[Michael Van Canneyt]

On Wed, 13 Apr 2016, Graeme Geldenhuys wrote:


On 2016-04-13 12:07, Michael Van Canneyt wrote:

If the PDF format does not support some form of clipping natively,
then it should not go in fpPDF.



PDF supports native clipping on all graphic elements. Glyphs are part of
the graphic elements.


Excellent, no problem then :-)

Michael.

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] fpPDF: set clip rect for text

[Graeme Geldenhuys]

On 2016-04-13 12:07, Michael Van Canneyt wrote:
> If the PDF format does not support some form of clipping natively,
> then it should not go in fpPDF.


PDF supports native clipping on all graphic elements. Glyphs are part of
the graphic elements.

The only clipping we currently implement is the MediaBox (ie: the size
of the page).

In case somebody else wanted to implement clipping earlier than I can.
See page 123 (table 4.1) in the PDF v1.3 specification document.
Clipping Paths (W & W*) and Graphics state (q & Q most likely).

Regards,
  - Graeme -

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] fpPDF: cannot embed DejaVu font

[Graeme Geldenhuys]

On 2016-04-13 10:54, Ondrej Pokorny wrote:
> Am I doing something wrong or is this a bug in fpPDF?

It's a bug. The BaseFont, FontName and FontFamily names (in fact any
PDFName elemens) may not contain spaces and should be escaped (or
encoded). I've fixed it locally, and the patch should be in FPC
hopefully some time today.

Thanks for reporting the issue.

Regards,
  - Graeme -

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] fpPDF: set clip rect for text

[Michael Van Canneyt]

On Wed, 13 Apr 2016, Graeme Geldenhuys wrote:


On 2016-04-12 20:25, Ondrej Pokorny wrote:

I need to clip text (e.g. in a table column). Is this already supported?


No, I haven't done any work on using the clipping operators yet. In
fpReport, text is rather wrapped than clipped.

Contributions in this regard are obviously very welcome. I would imagine
if the clipping operators are to be implemented, then graphics state
(save & restore) would probably go hand-in-hand with the clipping too.



A small remark:

If the PDF format does not support some form of clipping natively, then it 
should not go in fpPDF.

But it should instead be implemented in a layer on top of fppdf, such as the 
planned TPDFCanvas.

Keep your designs orthogonal, please.

Michael.

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] wiki page "Better_Unicode_Support_in_Lazarus"

[Michael Schnell]

On 04/13/2016 11:08 AM, Sven Barth wrote:


The code pages that are relevant here are only single byte code pages 
(e.g. CP1252) or UTF-8, *never* UTF-16 as a AnsiString can not store 
UTF-16 data.




StringCodePage(s) with an unqualified String return 0 (which is 
"CP_ACP", and seemingly means "Default").


But how to determine what encoding this default is, if (as we found) it 
can't be DefaultSystemCodePage and can be UTF16, which is dynamic, while 
the default for unqualified strings is static and *never* UTF-16 ?


Michael

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] wiki page "Better_Unicode_Support_in_Lazarus"

[Michael Schnell]

On 04/13/2016 11:08 AM, Sven Barth wrote:


The code pages that are relevant here are only single byte code pages 
(e.g. CP1252) or UTF-8, *never* UTF-16 as a AnsiString can not store 
UTF-16 data.


I see. And using 8 bit encoding as the brand for not the explicitly 
user-defind "String" type does make sense for a compiler that is 
supposed to create executables for multiple OSes does make prefect sense.


But AFAIK, Unicode aware Delphi uses UTF16 for the not the explicitly 
user-defind "String" type. (While AFAIK, not Unicode aware Delphi can't 
handle UTF8.)


So this is not compatible to either of them. In fact I am not asking for 
such compatibility (let alone that the two Delphi variants are even more 
incompatible to each other), but we need to be aware of the issue.


-Michael

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

[Lazarus] fpPDF: cannot embed DejaVu font

[Ondrej Pokorny]

I wanted to use the DejaVuLGCSans.ttf font from 
http://dejavu-fonts.org/wiki/Download

http://sourceforge.net/projects/dejavu/files/dejavu/2.35/dejavu-lgc-fonts-ttf-2.35.zip

The created PDF is corrupt. Adobe Acrobat Reader shows:


Adobe Illustrator:


Opera opens the file without problems, though.

If I change the font to FreeSans.ttf, the generated PDF is OK.

See the test project (with included font file): 
https://drive.google.com/open?id=0Bx-flYubOTroOTVudTAxYkJkTW8


Am I doing something wrong or is this a bug in fpPDF?

Ondrej


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] fpPDF: set clip rect for text

[Graeme Geldenhuys]

On 2016-04-12 20:25, Ondrej Pokorny wrote:
> I need to clip text (e.g. in a table column). Is this already supported? 

No, I haven't done any work on using the clipping operators yet. In
fpReport, text is rather wrapped than clipped.

Contributions in this regard are obviously very welcome. I would imagine
if the clipping operators are to be implemented, then graphics state
(save & restore) would probably go hand-in-hand with the clipping too.

Regards,
  - Graeme -



--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] wiki page "Better_Unicode_Support_in_Lazarus"

[Sven Barth]

Am 13.04.2016 10:19 schrieb "Michael Schnell" :
>
> BTW. according to the said wiki page (at the end of the page) I am wrong
assuming that DefaultSystemCodePage is a constant introduced by the
compiler.
>
> Now I still don't know whether/how the default encoding for the type
"String (which is different from DefaultSystemCodePage according to the
wiki) is depending on the arch/OS the compiler is built for. (I only tested
on Linux and here it rather obviously is UTF8. I assume on Windows it's
UTF16 for Delphi compatibility).
>

The code pages that are relevant here are only single byte code pages (e.g.
CP1252) or UTF-8, *never* UTF-16 as a AnsiString can not store UTF-16 data.

And the DefaultSystemCodePage is determined upon startup from the system.

Regards,
Sven
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] wiki page "Better_Unicode_Support_in_Lazarus"

[Mattias Gaertner]

On Wed, 13 Apr 2016 09:59:33 +0200
Michael Schnell  wrote:

>[...]
> http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus

Good page.


> Now I did some test and asked ob that list and found that the default 
> code page for the type "String" and with that the definition of  of 
> TStrings and with that the working of TStringList.Add and friends 
> depends on the setting of "DefaultSystemcodepage".

The "type" of String does not change.

> I understand that 
> DefaultSystemcodepage is set when compiling the compiler (e.g. to UTF-8 
> on Linux and (supposedly) to UTF-16 in Windows).

No. DefaultSystemcodepage is set at runtime. By the RTL and the
widestring manager.
Lazarus unit LazUTF8 sets it to CP_UTF8.
 
Mattias

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] wiki page "Better_Unicode_Support_in_Lazarus"

[Graeme Geldenhuys]

On 2016-04-13 09:19, Michael Schnell wrote:
> I assume on 
> Windows it's UTF16 for Delphi compatibility

No, that is not correct, at least for {$mode objfpc}. Maybe {$mode
delphi} is different, I'm not sure. The system code page varies based on
locale settings. I just went through this exercise with fcl-pdf.

Regards,
  - Graeme -

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] wiki page "Better_Unicode_Support_in_Lazarus"

[Michael Schnell]

BTW. according to the said wiki page (at the end of the page) I am wrong 
assuming that DefaultSystemCodePage is a constant introduced by the 
compiler.


Now I still don't know whether/how the default encoding for the type 
"String (which is different from DefaultSystemCodePage according to the 
wiki) is depending on the arch/OS the compiler is built for. (I only 
tested on Linux and here it rather obviously is UTF8. I assume on 
Windows it's UTF16 for Delphi compatibility).


-Michael

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

[Lazarus] wiki page "Better_Unicode_Support_in_Lazarus"

[Michael Schnell]

There was a discussion in the fpc -pascal mailing list about a question  
a user (tobiasgiesen) asked (among other things) about storing strings 
of a certain encoding brand in a TStringList.


Here Juha recommended to read this page -> 
http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus


Now I did some test and asked ob that list and found that the default 
code page for the type "String" and with that the definition of  of 
TStrings and with that the working of TStringList.Add and friends 
depends on the setting of "DefaultSystemcodepage". I understand that 
DefaultSystemcodepage is set when compiling the compiler (e.g. to UTF-8 
on Linux and (supposedly) to UTF-16 in Windows).


So I suppose Lazarus can't do anything about that. Or are there plans to 
use different compilers /RTL variant to allow for 
"Better_Unicode_Support_in_Lazarus" (project depending potentially 
better performance  or better portability and Linux, explicitly using e.g. native pos() results instead of 
introducing CodePointPos(), ...)   ?


-Michael



--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus