From marc.battyani at fractalconcept.com  Wed Feb  4 11:25:54 2004
From: marc.battyani at fractalconcept.com (Marc Battyani)
Date: Wed, 4 Feb 2004 12:25:54 +0100
Subject: [cl-pdf-devel] Latest cl-pdf modifications
References: <wzid692663v.fsf@melbourne.laas.fr>
	<08e801c3e6b7$e9f50b20$0303a8c0@marc2>
Message-ID: <08aa01c3eb11$a75d0b10$0303a8c0@marc2>

Revision 10:
added a :stacked-series option to the histograms

Revision 9:
changed zlib (again!) for dynamic loading of the library in delivered
applications

Revision 8:
added a *default-encoding* special variable.

Revision 7:
added pdf meta information to documents.
corrected handling of the min/max-value in the charts.
[Thanks to Eric Marsden for theses patches]

Revision 6:
corrected typo

Revision 6:
Font names are case insensitive now.
(They remain case sensitive in the generated pdf document)

Marc




From marc.battyani at fractalconcept.com  Thu Feb  5 08:05:59 2004
From: marc.battyani at fractalconcept.com (Marc Battyani)
Date: Thu, 5 Feb 2004 09:05:59 +0100
Subject: [cl-pdf-devel] Fw: [cl-typesetting-devel] *print-base*
Message-ID: <0c5401c3ebbe$e44a8b30$0303a8c0@marc2>

I'm forwarding this email from the cl-typesetting-devel mailing list as it
is more about cl-pdf than cl-typesetting.
(Though cl-pdf-devel subscribers have probably also subscribed to
cl-typesetting-devel)

Marc

From: "Marc Battyani" <marc.battyani at fractalconcept.com>
To: <cl-typesetting-devel at common-lisp.net>; "Frode Vatvedt Fjeld"
<ffjeld at common-lisp.net>


> > I just checked out cl-typesetting, and it does look quite
> > nice. However, at first it produced PDF-files unnacceptable to acrobat
> > or ghostview. After a while I remembered my previous attempt at
> > running cl-pdf and there being a problem with my having *print-base*
> > and *print-radix* not 10 and nil. So is the case with cl-typesetting,
> > apparently. Or it's still a cl-pdf problem. Anyway, while
> >
> > CL-USER(249): (typeset::ex #p"ex.pdf")
> >
> > doesn't work for me,
> >
> > CL-USER(250): (let ((*print-radix* nil)
> >     (*print-base* 10))
> >   (typeset::ex #p"ex.pdf"))
> >
> > does work. I'd suggest replacing some generic writes with (format
> > .. "~D" ..), or wrapping some strategic functions in
> > with-standard-io-syntax.
>
> Corrected. It was cl-pdf issue. I thought I corrected it already but it
was
> not the case.
> Can you check it again ?
> You need to recompile cl-typesetting after cl-pdf.
>
> Marc
>
> _______________________________________________
> cl-typesetting-devel site list
> cl-typesetting-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/cl-typesetting-devel




From divanov at aha.ru  Thu Feb  5 09:37:18 2004
From: divanov at aha.ru (Dmitri Ivanov)
Date: Thu, 5 Feb 2004 12:37:18 +0300
Subject: [cl-pdf-devel] National language support and other proposals
References: <wzid692663v.fsf@melbourne.laas.fr><08e801c3e6b7$e9f50b20$0303a8c0@marc2>
	<08aa01c3eb11$a75d0b10$0303a8c0@marc2>
Message-ID: <001001c3ebcb$c439da00$6e4302c3@digo>

Hello,

1. National Language Support

First, it is hardly possible to transfer binary data to a file in
non-Latin-1 external format. So I vote for opening PDF file as a binary
stream, not a character stream. In my code, this is the choice when the
pdf-binary feature is on.

Second, I suggest zlib compress-string returning (vector (unsigned-byte 8))
instead of a string. My version of zlib-lw.lisp is an example.

The benefit would be better control over char-to-byte conversion. The
drawback is that we should always do this manually :-). Only two
write-object methods would be affected if we limited ourselves by using
national characters only in contents streams.

2. Fonts

Unfortunately, I have failed referring to TrueType fonts without embedding
them. So I converted them to Type1 subsets and experimented.

2.1. Embedding Fonts

IMHO, one useful option could be not embed a custom Type1 font into a
document provided it had already installed on the target computer. The
following primitives can do:

(defvar *embed-fonts* :default)
(defgeneric font-descriptor (font-metrics &key embed errorp))

2.2. Some fixes are needed in case the pfb-file is missing and/or the
afm-file is limited, e.g. was generated from an pfm, e.g.

(defun load-t1-font (afm-file &optional pfb-file) ...)

3. Encoding

I suggest renaming the slot standard-encoding to standard-p or built-in-p
(in order not to correlate with *standard-encoding*); alternatively, remove
it and introduce a subclass, named
built-in-encoding.

For custom needs, I propose:

(defclass custom-encoding (encoding)
((base-encoding :initarg :base-encoding :reader base-encoding :initform
nil)))

The value of *win-1251-encoding*, an instance of the custom-encoding class,
was generated in that manner in accordance with Adobe's glyph list.

For flexibility, compute-encoding-differences could be redefined as follows
(defun compute-encoding-differences
      (encoding &optional (from *standard-encoding*))

Though :win-ansi-encoding gets better results for installed fonts that are
not embedded, but basing a custom encoding on it via /BaseEncoding
completely fails for embedded Type1 fonts!

Hence the question: can we do with *default-encoding* as the default value
of the encoding parameter of get-font? It seems that get-font should not
provide any default for it. Instead, if it is null, the
extract-font-metrics-encoding tries to extract it from the font metrics.
IMHO, extract-font-metrics-encoding should be enhanced to convert
EncodingScheme "AdobeStandardEncoding" to :standard-encoding and the like.
Adding a encoding parameter the read-afm-file function that is to be used as
a substitution of "FontSpecific" EncodingScheme in is also a choice.

4. PDF Dictionaries

I suggest the following generic function to create dictionaries in a more
regular way:
(defgeneric make-dictionary (thing &key &allow-other-keys))

For dictionary property names, I would recommend using symbols like
| /Length| or keywords with corresponding string set as properties, e.g.:

(setf (get :length 'pdf:namestring) "/Length")
(defmethod write-object ((obj keyword) &optional root-level)
  (declare (ignorable root-level))
  (write-string (or (get obj 'pdf:namestring) (symbol-name obj))
             *pdf-stream*))

Strings are quite enough for the time being (generation), but could lead to
excessive memory consumption and performance degradation for more complex tasks:
parsing and editing.

5. Code Restructure

5.1. (defclass pdf-stream (dictionary)
   (...(no-compression :accessor no-compression
:initarg :no-compression :initform nil)))

I would rename the no-compression slot to 'compression' and assign a decode
filter designator to it, e.g. |Flate|, t (equivalent to |Flate|), or other.

5.2. Slightly misnomers
  find-font-object
  find-encoding-object
  find-gstate-object
I would prefer find-or-make- or ensure- (more CLOS-like).


6. My Test Environment

I have tested all the examples listed in the /examples directory on LWW 4.3
and they seemed to work fine. I neither included init.lisp nor zlib.lisp nor
t3-fonts in my test environment, nor asdf installation. Instead, I used LW
defsys augmented by zliw-lw.lisp and di-contrib.lisp.

BTW I ran into a useful resource, http://www.fpdf.org/
These guys make the same thing in Perl, expose source code, and provide some
useful hints in the forum.
--
Sincerely,
Dmitri Ivanov
lisp.ystok.ru
-------------- next part --------------
A non-text attachment was scrubbed...
Name: all.diff
Type: application/octet-stream
Size: 3067 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cl-pdf-devel/attachments/20040205/96ab7047/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zlib-lw.lisp
Type: application/octet-stream
Size: 4700 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cl-pdf-devel/attachments/20040205/96ab7047/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: di-contrib.zip
Type: application/x-zip-compressed
Size: 4575 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cl-pdf-devel/attachments/20040205/96ab7047/attachment.bin>

From marc.battyani at fractalconcept.com  Thu Feb  5 14:18:41 2004
From: marc.battyani at fractalconcept.com (Marc Battyani)
Date: Thu, 5 Feb 2004 15:18:41 +0100
Subject: [cl-pdf-devel] National language support and other proposals
References: <wzid692663v.fsf@melbourne.laas.fr><08e801c3e6b7$e9f50b20$0303a8c0@marc2><08aa01c3eb11$a75d0b10$0303a8c0@marc2>
	<001001c3ebcb$c439da00$6e4302c3@digo>
Message-ID: <0e5f01c3ebf2$f5607c20$0303a8c0@marc2>

"Dmitri Ivanov" <divanov at aha.ru> writes:
> Hello,

Hi  Dmitri,

> 1. National Language Support
>
> First, it is hardly possible to transfer binary data to a file in
> non-Latin-1 external format. So I vote for opening PDF file as a binary
> stream, not a character stream. In my code, this is the choice when the
> pdf-binary feature is on.
>
> Second, I suggest zlib compress-string returning (vector (unsigned-byte
8))
> instead of a string. My version of zlib-lw.lisp is an example.
>
> The benefit would be better control over char-to-byte conversion. The
> drawback is that we should always do this manually :-). Only two
> write-object methods would be affected if we limited ourselves by using
> national characters only in contents streams.

I agree with you that this would be a better way. But these encoding and
binary stream issues are really, really touchy.
What works with LWW might not work on other implementations even if the have
bivalent streams or even on other OS (LWL for instance)

> 2. Fonts
>
> Unfortunately, I have failed referring to TrueType fonts without embedding
> them. So I converted them to Type1 subsets and experimented.
>
> 2.1. Embedding Fonts
>
> IMHO, one useful option could be not embed a custom Type1 font into a
> document provided it had already installed on the target computer. The
> following primitives can do:
>
> (defvar *embed-fonts* :default)
> (defgeneric font-descriptor (font-metrics &key embed errorp))

ok. You must be sure that the user have them though.

> 2.2. Some fixes are needed in case the pfb-file is missing and/or the
> afm-file is limited, e.g. was generated from an pfm, e.g.
>
> (defun load-t1-font (afm-file &optional pfb-file) ...)

ok, but the italic-correction must be a number. (0 if no bbox)
And if there is no bbox, I don't see how you can use the font. Or it's a
fixed size font, in that case the bbox should be the one defined for the
font.

> 3. Encoding
>
> I suggest renaming the slot standard-encoding to standard-p or built-in-p
> (in order not to correlate with *standard-encoding*); alternatively,
remove
> it and introduce a subclass, named
> built-in-encoding.
>
> For custom needs, I propose:
>
> (defclass custom-encoding (encoding)
> ((base-encoding :initarg :base-encoding :reader base-encoding :initform
> nil)))

ok

> The value of *win-1251-encoding*, an instance of the custom-encoding
class,
> was generated in that manner in accordance with Adobe's glyph list.

ok

> For flexibility, compute-encoding-differences could be redefined as
follows
> (defun compute-encoding-differences
>       (encoding &optional (from *standard-encoding*))

ok, have you verified that this does not yield to problems with standard
fonts ?
IIRC there was a problem with the encoding differences this is why I ended
up with the whole encoding.

> Though :win-ansi-encoding gets better results for installed fonts that are
> not embedded, but basing a custom encoding on it via /BaseEncoding
> completely fails for embedded Type1 fonts!
>
> Hence the question: can we do with *default-encoding* as the default value
> of the encoding parameter of get-font? It seems that get-font should not
> provide any default for it. Instead, if it is null, the
> extract-font-metrics-encoding tries to extract it from the font metrics.
> IMHO, extract-font-metrics-encoding should be enhanced to convert
> EncodingScheme "AdobeStandardEncoding" to :standard-encoding and the like.
> Adding a encoding parameter the read-afm-file function that is to be used
as
> a substitution of "FontSpecific" EncodingScheme in is also a choice.

I will look at this in more details.

> 4. PDF Dictionaries
>
> I suggest the following generic function to create dictionaries in a more
> regular way:
> (defgeneric make-dictionary (thing &key &allow-other-keys))


ok

> For dictionary property names, I would recommend using symbols like
> | /Length| or keywords with corresponding string set as properties, e.g.:
>
> (setf (get :length 'pdf:namestring) "/Length")
> (defmethod write-object ((obj keyword) &optional root-level)
>   (declare (ignorable root-level))
>   (write-string (or (get obj 'pdf:namestring) (symbol-name obj))
>              *pdf-stream*))
>
> Strings are quite enough for the time being (generation), but could lead
to
> excessive memory consumption and performance degradation for more complex
tasks:
> parsing and editing.


When you parse a pdf file, the major amount of data is in the streams, not
in the dictionaries.
So why not? But there are a lot of more important points to improve from a
performance point of view. (I have some ideas if you want... ;-)

> 5. Code Restructure
>
> 5.1. (defclass pdf-stream (dictionary)
>    (...(no-compression :accessor no-compression
> :initarg :no-compression :initform nil)))
>
> I would rename the no-compression slot to 'compression' and assign a
decode
> filter designator to it, e.g. |Flate|, t (equivalent to |Flate|), or
other.


OK but there are no other compression scheme for now. (in cl-pdf)

> 5.2. Slightly misnomers
>   find-font-object
>   find-encoding-object
>   find-gstate-object
> I would prefer find-or-make- or ensure- (more CLOS-like).

Yes. I also like ensure.

> 6. My Test Environment
>
> I have tested all the examples listed in the /examples directory on LWW
4.3
> and they seemed to work fine. I neither included init.lisp nor zlib.lisp
nor
> t3-fonts in my test environment, nor asdf installation. Instead, I used LW
> defsys augmented by zliw-lw.lisp and di-contrib.lisp.


A good test is to run the cl-typesetting example. ;-)
An even better test test would be to add a Russian paragraph to the
cl-typesetting example.

> BTW I ran into a useful resource, http://www.fpdf.org/
> These guys make the same thing in Perl, expose source code, and provide
some
> useful hints in the forum.

Interesting I will have a look.

Thanks for all these improvements!

I will merge most of them ASAP. Some others would require testing on other
implementations and/or OS before I include them.

Marc




From marc.battyani at fractalconcept.com  Thu Feb  5 17:53:00 2004
From: marc.battyani at fractalconcept.com (Marc Battyani)
Date: Thu, 5 Feb 2004 18:53:00 +0100
Subject: [cl-pdf-devel] New version
References: <wzid692663v.fsf@melbourne.laas.fr><08e801c3e6b7$e9f50b20$0303a8c0@marc2><08aa01c3eb11$a75d0b10$0303a8c0@marc2>
	<001001c3ebcb$c439da00$6e4302c3@digo>
Message-ID: <0f3001c3ec10$e5f338e0$0303a8c0@marc2>

There is a new version of cl-pdf in the repository. (rev 13)

I merged most of the suggestions from Dmitri Ivanov excepted the binary
format for the pdf files, which would need more testing to avoid messing
with portability on other implementations and/or OS.

I used cl-typesetting as an integrity check.

Marc




From divanov at aha.ru  Fri Feb  6 15:10:15 2004
From: divanov at aha.ru (Dmitri Ivanov)
Date: Fri, 6 Feb 2004 18:10:15 +0300
Subject: [cl-pdf-devel] National language support and other proposals
References: <wzid692663v.fsf@melbourne.laas.fr><08e801c3e6b7$e9f50b20$0303a8c0@marc2><08aa01c3eb11$a75d0b10$0303a8c0@marc2>
	<001001c3ebcb$c439da00$6e4302c3@digo>
	<0e5f01c3ebf2$f5607c20$0303a8c0@marc2>
Message-ID: <000d01c3ecc3$8ecddda0$da5702c3@digo>

Hello Marc,

| "Dmitri Ivanov" <divanov at aha.ru> writes:
|> Hello,
|...snip...|
|> (defun load-t1-font (afm-file &optional pfb-file) ...)
|
| ok, but the italic-correction must be a number. (0 if no bbox)
| And if there is no bbox, I don't see how you can use the font. Or it's
| a fixed size font, in that case the bbox should be the one defined for
| the font.

Could we derive the bbox of a char from its width and the font bbox?

|> The value of *win-1251-encoding*, an instance of the custom-encoding
|> class, was generated in that manner in accordance with Adobe's glyph
|> list.
|
| ok

I guess, a separate subdirectory named "lang" or "locale" would be a good
place for NLS code.


|> For flexibility, compute-encoding-differences could be redefined as
| follows
|> (defun compute-encoding-differences
|>       (encoding &optional (from *standard-encoding*))
|
| ok, have you verified that this does not yield to problems with
| standard fonts ?
| IIRC there was a problem with the encoding differences this is why I
| ended up with the whole encoding.

No, I haven't verified standard fonts with non-standard encodings because
standard fonts have nothing to do with Russian.

|> For dictionary property names, I would recommend using symbols like
| >> /Length| or keywords with corresponding string set as properties,
| >> e.g.: (setf (get :length 'pdf:namestring) "/Length")

Sorry, I meant to say |Length| or
    (setf (get :length 'pdf:namestring) "Length")
- without a leading slash.

| ... But there are a lot of more important points to improve
| from a performance point of view. (I have some ideas if you want... ;-)

Not so fast, please :-)
--
Sincerely,
Dmitri Ivanov
lisp.ystok.ru




From marc.battyani at fractalconcept.com  Fri Feb  6 15:32:14 2004
From: marc.battyani at fractalconcept.com (Marc Battyani)
Date: Fri, 6 Feb 2004 16:32:14 +0100
Subject: [cl-pdf-devel] National language support and other proposals
References: <wzid692663v.fsf@melbourne.laas.fr><08e801c3e6b7$e9f50b20$0303a8c0@marc2><08aa01c3eb11$a75d0b10$0303a8c0@marc2><001001c3ebcb$c439da00$6e4302c3@digo><0e5f01c3ebf2$f5607c20$0303a8c0@marc2>
	<000d01c3ecc3$8ecddda0$da5702c3@digo>
Message-ID: <136c01c3ecc6$6655e1d0$0303a8c0@marc2>

"Dmitri Ivanov" <divanov at aha.ru> writes :


> | ok, but the italic-correction must be a number. (0 if no bbox)
> | And if there is no bbox, I don't see how you can use the font. Or it's
> | a fixed size font, in that case the bbox should be the one defined for
> | the font.
>
> Could we derive the bbox of a char from its width and the font bbox?

If there is no bbox specified for the char I just put the font-bbox instead.
The bbox is not used in general anyway I just use it to compute the italic
corrections IIRC.

> |> The value of *win-1251-encoding*, an instance of the custom-encoding
> |> class, was generated in that manner in accordance with Adobe's glyph
> |> list.
> |
> | ok
>
> I guess, a separate subdirectory named "lang" or "locale" would be a good
> place for NLS code.

yes.

> |> For flexibility, compute-encoding-differences could be redefined as
> | follows
> |> (defun compute-encoding-differences
> |>       (encoding &optional (from *standard-encoding*))
> |
> | ok, have you verified that this does not yield to problems with
> | standard fonts ?
> | IIRC there was a problem with the encoding differences this is why I
> | ended up with the whole encoding.
>
> No, I haven't verified standard fonts with non-standard encodings because
> standard fonts have nothing to do with Russian.

I've put back the whole encoding when it's not a custom-encoding.

> |> For dictionary property names, I would recommend using symbols like
> | >> /Length| or keywords with corresponding string set as properties,
> | >> e.g.: (setf (get :length 'pdf:namestring) "/Length")
>
> Sorry, I meant to say |Length| or
>     (setf (get :length 'pdf:namestring) "Length")
> - without a leading slash.
>
> | ... But there are a lot of more important points to improve
> | from a performance point of view. (I have some ideas if you want... ;-)
>
> Not so fast, please :-)

:)

Marc




From Marc.Battyani at fractalconcept.com  Sun Feb  8 15:44:13 2004
From: Marc.Battyani at fractalconcept.com (Marc Battyani)
Date: Sun, 8 Feb 2004 16:44:13 +0100
Subject: [cl-pdf-devel] [ANNOUNCE] cl-pdf release 2.1
Message-ID: <095701c3ee5a$6900e700$0303a8c0@marc2>

CL-PDF is a cross-platform Common Lisp library for generating PDF files.
It does not need any third-party tools from Adobe or others.
It is used by cl-typesetting to provide a complete typesetting system.

>From the change log:

08 February 2004: Release 2.1
   Added auto-generated tarballs of the current repository version
   Added custom encodings.  [Thanks to Dmitri Ivanov]
   Fonts without font data. [Thanks to Dmitri Ivanov]
   Added a few with-standard-io-syntax so that the pdf are generated
         correctly when people change the printer settings.
   Added a :stacked-series option to the histograms.
   Changed zlib (again!) for dynamic loading of the library in delivered
applications.
   Added a *default-encoding* special variable.
   Added pdf meta information to documents.[Thanks to Eric Marsden]
   Corrected handling of the min/max-value in the charts.[Thanks to Eric
Marsden]
   Corrected pfb file loading.
   Font names are case insensitive now.
   Added improved code128 barcodes [Thanks to Lars Rustemeier].

The cl-pdf home page is here:
http://www.fractalconcept.com/asp/html/cl-pdf.html

Marc






From divanov at aha.ru  Mon Feb  9 09:47:54 2004
From: divanov at aha.ru (Dmitri Ivanov)
Date: Mon, 9 Feb 2004 12:47:54 +0300
Subject: [cl-pdf-devel] National language support and other proposals
References: <wzid692663v.fsf@melbourne.laas.fr><08e801c3e6b7$e9f50b20$0303a8c0@marc2><08aa01c3eb11$a75d0b10$0303a8c0@marc2><001001c3ebcb$c439da00$6e4302c3@digo><0e5f01c3ebf2$f5607c20$0303a8c0@marc2>
	<000d01c3ecc3$8ecddda0$da5702c3@digo>
	<136c01c3ecc6$6655e1d0$0303a8c0@marc2>
Message-ID: <002301c3eef2$4bf43de0$945702c3@digo>

Hello,

Here is another milestone on my way to the subject.

IMHO we should replace all calls of (concatenate 'string ...) by
(string-append ...) in all code places where arguments may contain non-base
characters. On LW, this is trivially matches lw:string-append, which
constructs a string of the same type as the argument with the largest
element type:
(defmacro string-append (&rest args)
  #+lispworks `(lw:string-append , at args)
  #-lispworks `(concatenate 'string , at args))

Other improvements deal with PDF null object and decoding RGBs uniformly -
see the attachment.
--
Sincerely,
Dmitri Ivanov
www.ystok.ru
-------------- next part --------------
A non-text attachment was scrubbed...
Name: di-contrib-20040209.lisp
Type: application/octet-stream
Size: 2926 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cl-pdf-devel/attachments/20040209/7db20d52/attachment.obj>

From marc.battyani at fractalconcept.com  Mon Feb  9 20:22:59 2004
From: marc.battyani at fractalconcept.com (Marc Battyani)
Date: Mon, 9 Feb 2004 21:22:59 +0100
Subject: [cl-pdf-devel] National language support and other proposals
References: <wzid692663v.fsf@melbourne.laas.fr><08e801c3e6b7$e9f50b20$0303a8c0@marc2><08aa01c3eb11$a75d0b10$0303a8c0@marc2><001001c3ebcb$c439da00$6e4302c3@digo><0e5f01c3ebf2$f5607c20$0303a8c0@marc2><000d01c3ecc3$8ecddda0$da5702c3@digo><136c01c3ecc6$6655e1d0$0303a8c0@marc2>
	<002301c3eef2$4bf43de0$945702c3@digo>
Message-ID: <17e101c3ef4a$8389f260$0303a8c0@marc2>

> Here is another milestone on my way to the subject.

Great!

> IMHO we should replace all calls of (concatenate 'string ...) by
> (string-append ...) in all code places where arguments may contain
non-base
> characters. On LW, this is trivially matches lw:string-append, which
> constructs a string of the same type as the argument with the largest
> element type:
> (defmacro string-append (&rest args)
>   #+lispworks `(lw:string-append , at args)
>   #-lispworks `(concatenate 'string , at args))
>
> Other improvements deal with PDF null object and decoding RGBs uniformly -
> see the attachment.

Handling null values in the dictionnaries is a good point but why do you use
a *null* instead of nil ?
This make the code more tedious and will force user code to deal with
pdf:*null* wich is not very nice.

I'm merging the rest to cl-pdf. :)

Marc




From marc.battyani at fractalconcept.com  Mon Feb  9 22:06:45 2004
From: marc.battyani at fractalconcept.com (Marc Battyani)
Date: Mon, 9 Feb 2004 23:06:45 +0100
Subject: [cl-pdf-devel] National language support and other proposals
References: <wzid692663v.fsf@melbourne.laas.fr><08e801c3e6b7$e9f50b20$0303a8c0@marc2><08aa01c3eb11$a75d0b10$0303a8c0@marc2><001001c3ebcb$c439da00$6e4302c3@digo><0e5f01c3ebf2$f5607c20$0303a8c0@marc2><000d01c3ecc3$8ecddda0$da5702c3@digo><136c01c3ecc6$6655e1d0$0303a8c0@marc2>
	<002301c3eef2$4bf43de0$945702c3@digo>
Message-ID: <186c01c3ef59$02638430$0303a8c0@marc2>

Dmitri Ivanov <divanov at aha.ru> writes:

> IMHO we should replace all calls of (concatenate 'string ...) by
> (string-append ...) in all code places where arguments may contain
non-base
> characters. On LW, this is trivially matches lw:string-append, which
> constructs a string of the same type as the argument with the largest
> element type:
> (defmacro string-append (&rest args)
>   #+lispworks `(lw:string-append , at args)
>   #-lispworks `(concatenate 'string , at args))

OK, I've put it where it can be useful IMO.
Users of other implementations are invited to send patches that works for
them...

> Other improvements deal with PDF null object and decoding RGBs uniformly -
> see the attachment.

I've committed the changes to the repository.

Marc




From divanov at aha.ru  Tue Feb 10 06:01:11 2004
From: divanov at aha.ru (Dmitri Ivanov)
Date: Tue, 10 Feb 2004 09:01:11 +0300
Subject: [cl-pdf-devel] National language support and other proposals
References: <wzid692663v.fsf@melbourne.laas.fr><08e801c3e6b7$e9f50b20$0303a8c0@marc2><08aa01c3eb11$a75d0b10$0303a8c0@marc2><001001c3ebcb$c439da00$6e4302c3@digo><0e5f01c3ebf2$f5607c20$0303a8c0@marc2><000d01c3ecc3$8ecddda0$da5702c3@digo><136c01c3ecc6$6655e1d0$0303a8c0@marc2>
	<002301c3eef2$4bf43de0$945702c3@digo>
	<17e101c3ef4a$8389f260$0303a8c0@marc2>
Message-ID: <000001c3ef9c$51f2a920$c25702c3@digo>

Hello Marc,

| Handling null values in the dictionnaries is a good point but why do
| you use a *null* instead of nil ?
| This make the code more tedious and will force user code to deal with
| pdf:*null* wich is not very nice.

It is just a matter of habit :-) Due to my limited knowledge of the domain,
I am not able to predict all situations where its null object is used. So I
prefer dedicating a parameter for it, like sql:*null*.

Naturally, I trust your experience if you say that nil will do.
--
Sincerely,
Dmitri Ivanov
lisp.ystok.ru




From peter at javamonkey.com  Mon Feb 16 22:52:55 2004
From: peter at javamonkey.com (Peter Seibel)
Date: Mon, 16 Feb 2004 22:52:55 -0000
Subject: [cl-pdf-devel] Patch to clean up pdf-utils.
Message-ID: <m3u11qskct.fsf@javamonkey.com>

So I was poking around in the cl-pdf code and noticed that most of
pdf-utils is duplicated in pdf-base. Looking at the .asd file it looks
like pdf-utils isn't used at all so perhaps it can simply be deleted.
In the meantime here's a patch that removes all the code that is
duplicated exactly in pdf-base. Of what's left, about half are
functions that differ only slightly from the version in pdf-base.

-Peter

Index: pdf-utils.lisp
===================================================================
--- pdf-utils.lisp	(revision 16)
+++ pdf-utils.lisp	(working copy)
@@ -15,31 +15,10 @@
 (defun set-font (font size)
   (format *page-stream* "~a ~,2f Tf~%" (name font) size))
 
-(defmacro def-pdf-op (name (&rest args) format)
-  (if args
-    `(defun ,name ,args (format *page-stream* ,format , at args))
-    `(defun ,name () (write-line ,format *page-stream*))))
-
-(def-pdf-op move-text (dx dy) "~,3f ~,3f Td~%")
-
-(def-pdf-op draw-text (string) "(~a) Tj~%")
-
 (def-pdf-op draw-text-on-next-line (string) "(~a) '~%")
 
-(def-pdf-op set-text-rendering-mode (mode) "~d Tr~%")
-
-(def-pdf-op set-char-spacing (space) "~,3f Tc~%")
-
-(def-pdf-op set-text-x-scale (scale) "~,3f Tz~%")
-
-(def-pdf-op set-text-leading (space) "~,3f TL~%")
-
-(def-pdf-op set-text-rise (rise) "~,3f Ts~%")
-
 (def-pdf-op move-to-next-line () " T*~%")
 
-(def-pdf-op set-text-matrix (a b c d e f) "~,3f ~,3f ~,3f ~,3f ~,3f ~,3f Tm~%")
-
 (defun draw-and-adjust-string (strings)
   (write-string "[ " *page-stream*)
   (dolist (item strings)
@@ -50,88 +29,5 @@
 
 ;;; graphic functions
 
-(defmacro with-saved-state (&body body)
-  `(unwind-protect
-     (progn (write-line "q" *page-stream*)
-	    , at body)
-    (write-line "Q" *page-stream*)))
-
-(def-pdf-op set-transform-matrix (a b c d e f) "~,3f ~,3f ~,3f ~,3f ~,3f ~,3f cm~%")
-
-(def-pdf-op translate (dx dy) "1.0 0.0 0.0 1.0 ~,3f ~,3f cm~%")
-
-(defun rotate (deg)
-  (let* ((angle (/ (* pi deg) 180.0))
-	 (s (sin angle))
-	 (c (cos angle)))
-    (format *page-stream* "~,3f ~,3f ~,3f ~,3f 0.0 0.0 cm~%" c s (- s) c)))
-
-(def-pdf-op scale (sx sy) " ~,3f 0.0 0.0 ~,3f 0.0 0.0 cm~%")
-
-(defun skew (x-deg y-deg)
-  (format *page-stream* " 1.0 ~,3f ~,3f 1.0 0.0 0.0 cm~%"
-	  (tan (/ (* pi x-deg) 180.0))(tan (/ (* pi y-deg) 180.0))))
-
-(def-pdf-op set-line-width (width) "~,3f w~%")
-
-(def-pdf-op set-line-cap (mode) "~d J~%")
-
-(def-pdf-op set-line-join (mode) "~d j~%")
-
 (def-pdf-op set-dash-pattern (dash-array phase) "[~{~d~^ ~}] ~d~%")
 
-(def-pdf-op set-mitter-limit (limit) "~,3f M~%")
-
-(def-pdf-op move-to (x y) "~,3f ~,3f m~%")
-
-(def-pdf-op line-to (x y) "~,3f ~,3f l~%")
-
-(def-pdf-op bezier-to (x1 y1 x2 y2 x3 y3) "~,3f ~,3f ~,3f ~,3f ~,3f ~,3f c~%")
-
-(def-pdf-op bezier2-to (x2 y2 x3 y3) "~,3f ~,3f ~,3f ~,3f v~%")
-
-(def-pdf-op bezier3-to (x1 y1 x3 y3) "~,3f ~,3f ~,3f ~,3f y~%")
-
-(def-pdf-op close-path () " h")
-
-(def-pdf-op basic-rect (x y dx dy) "~,3f ~,3f ~,3f ~,3f re~%")
-
-(defun paint-image (image)
-  (format *page-stream* "~a Do~%" (name image)))
-
-(def-pdf-op stroke () " S")
-
-(def-pdf-op close-and-stroke () " s")
-
-(def-pdf-op fill-path () " f")
-
-(def-pdf-op close-and-fill () " h f")
-
-(def-pdf-op even-odd-fill () " f*")
-
-(def-pdf-op fill-and-stroke () " B")
-
-(def-pdf-op even-odd-fill-and-stroke () " B*")
-
-(def-pdf-op close-fill-and-stroke () " b")
-
-(def-pdf-op close-even-odd-fill-and-stroke () " b*")
-
-(def-pdf-op end-path-no-op  () " n")
-
-(def-pdf-op clip-path () " W")
-
-(def-pdf-op even-odd-clip-path () " W*")
-
-(def-pdf-op set-gray-stroke (gray) "~,3f G~%")
-
-(def-pdf-op set-gray-fill (gray) "~,3f g~%")
-
-(def-pdf-op set-rgb-stroke (r g b) "~,3f ~,3f ~,3f RG~%")
-
-(def-pdf-op set-rgb-fill (r g b) "~,3f ~,3f ~,3f rg~%")
-
-(def-pdf-op set-cymk-stroke (c y m k) "~,3f ~,3f ~,3f ~,3f K~%")
-
-(def-pdf-op set-cymk-fill (c y m k) "~,3f ~,3f ~,3f ~,3f k~%")
-



-- 
Peter Seibel                                      peter at javamonkey.com

         Lisp is the red pill. -- John Fraser, comp.lang.lisp



From marc.battyani at fractalconcept.com  Mon Feb 16 23:13:52 2004
From: marc.battyani at fractalconcept.com (Marc Battyani)
Date: Tue, 17 Feb 2004 00:13:52 +0100
Subject: [cl-pdf-devel] Patch to clean up pdf-utils.
References: <m3u11qskct.fsf@javamonkey.com>
Message-ID: <09b101c3f4e2$8c48bfb0$0303a8c0@marc2>

"Peter Seibel" <peter at javamonkey.com> writes:

> So I was poking around in the cl-pdf code and noticed that most of
> pdf-utils is duplicated in pdf-base. Looking at the .asd file it looks
> like pdf-utils isn't used at all so perhaps it can simply be deleted.
...

You are right it should have been deleted. I will remove it.

Marc



From peter at javamonkey.com  Tue Feb 17 01:38:58 2004
From: peter at javamonkey.com (Peter Seibel)
Date: Tue, 17 Feb 2004 01:38:58 -0000
Subject: [cl-pdf-devel] Getting bold version of current font?
Message-ID: <m3hdxqsco3.fsf@javamonkey.com>

Is there any automatic way to get the font tha corresponds to the bold
version of the current font? I want to format a bit of text in bold
without necessarily knowing what font I'm in.

-Peter


-- 
Peter Seibel                                      peter at javamonkey.com

         Lisp is the red pill. -- John Fraser, comp.lang.lisp



From marc.battyani at fractalconcept.com  Thu Feb 26 10:14:02 2004
From: marc.battyani at fractalconcept.com (Marc Battyani)
Date: Thu, 26 Feb 2004 11:14:02 +0100
Subject: [cl-pdf-devel] The source code repositories are back
References: <m3hdxqsco3.fsf@javamonkey.com>
Message-ID: <033701c3fc51$42d4f8f0$0303a8c0@marc2>

The cl-pdf and cl-typesetting source code repositories are on-line again.

Marc



From erik at nittin.net  Thu Feb 26 20:52:10 2004
From: erik at nittin.net (Erik Enge)
Date: Thu, 26 Feb 2004 15:52:10 -0500
Subject: [cl-pdf-devel] Problem with write-document with stream as opposed
	to pathname
Message-ID: <A583F36C-689D-11D8-9105-000A95CEC334@nittin.net>

I get two substantially different documents if I call write-document 
with a stream and a pathname.
Ignoring creation date differences, in the one where I passed a stream 
to write-document, I observe
/CLF101 instead of /CLF104 (don't know if this matters).

But probably what makes my document generated via the stream unreadable 
in Adobe Acrobat
Reader version 6.0 for Mac OS X is the following:

0 10                                                0 10
0000000000 65535 f                  0000000000 65535 f
0000000009 00000 n                 0000000NIL 00000 n
0000000059 00000 n                 0000000NIL 00000 n
0000000145 00000 n                 0000000NIL 00000 n
0000000205 00000 n                 0000000NIL 00000 n
0000000223 00000 n                 0000000NIL 00000 n
0000000472 00000 n                 0000000NIL 00000 n
0000001952 00000 n                 0000000NIL 00000 n
0000002050 00000 n                 0000000NIL 00000 n
0000004364 00000 n                 0000000NIL 00000 n
trailer                                              trailer
<< /Size 10                                    << /Size 10
/Root 1 0 R/Info 2 0 R                  /Root 1 0 R/Info 2 0 R
 >>                                                    >>
startxref                                          startxref
4467                                               NIL
%%EOF                                         %%EOF


The right is where I passed write-document a pathname, the left, a 
stream.

Looking at the code in cl-pdf I don't see how this can happen so I'm 
wondering if
I have aggravated something else, somewhere else.  I am absolutely sure 
that the
only thing I am changing to reproduce this (it is fully reproducible) 
is whether I say

   (pdf:write-document #p"/tmp/test.pdf")

or

   (pdf:write-document *my-stream*)

Any clues?  I'm running cl-pdf 2.0 in LW 4.3.0 on Mac OS X 10.3.2.

Erik.




From erik at nittin.net  Thu Feb 26 20:56:20 2004
From: erik at nittin.net (Erik Enge)
Date: Thu, 26 Feb 2004 15:56:20 -0500
Subject: [cl-pdf-devel] Problem with write-document with stream as opposed
	to pathname
In-Reply-To: <A583F36C-689D-11D8-9105-000A95CEC334@nittin.net>
References: <A583F36C-689D-11D8-9105-000A95CEC334@nittin.net>
Message-ID: <3ACCE018-689E-11D8-9105-000A95CEC334@nittin.net>

On Feb 26, 2004, at 3:52 PM, Erik Enge wrote:

> The right is where I passed write-document a pathname, the left, a 
> stream.

Sorry, left is pathname, right is stream.

Erik.




From marc.battyani at fractalconcept.com  Thu Feb 26 20:59:32 2004
From: marc.battyani at fractalconcept.com (Marc Battyani)
Date: Thu, 26 Feb 2004 21:59:32 +0100
Subject: [cl-pdf-devel] Problem with write-document with stream as
	opposedto pathname
References: <A583F36C-689D-11D8-9105-000A95CEC334@nittin.net>
Message-ID: <06b501c3fcab$6f89e0e0$0303a8c0@marc2>

"Erik Enge" <erik at nittin.net> writes:


> I get two substantially different documents if I call write-document
> with a stream and a pathname.
> Ignoring creation date differences, in the one where I passed a stream
> to write-document, I observe
> /CLF101 instead of /CLF104 (don't know if this matters).
>
> But probably what makes my document generated via the stream unreadable
> in Adobe Acrobat
> Reader version 6.0 for Mac OS X is the following:
>
> 0 10                                                0 10
> 0000000000 65535 f                  0000000000 65535 f
> 0000000009 00000 n                 0000000NIL 00000 n
...

> The right is where I passed write-document a pathname, the left, a
> stream.
>
> Looking at the code in cl-pdf I don't see how this can happen so I'm
> wondering if
> I have aggravated something else, somewhere else.  I am absolutely sure
> that the
> only thing I am changing to reproduce this (it is fully reproducible)
> is whether I say
>
>    (pdf:write-document #p"/tmp/test.pdf")
>
> or
>
>    (pdf:write-document *my-stream*)
>
> Any clues?  I'm running cl-pdf 2.0 in LW 4.3.0 on Mac OS X 10.3.2.

Yes, you are probably using a stream for which file-position is not defined.

If you want to generate a PDF in memory, to send in a web server for
instance, you need to write it in a with-output-to-string and then write the
string to you real stream.

Marc




From erik at nittin.net  Thu Feb 26 21:15:19 2004
From: erik at nittin.net (Erik Enge)
Date: Thu, 26 Feb 2004 16:15:19 -0500
Subject: [cl-pdf-devel] Problem with write-document with stream as
	opposedto pathname
In-Reply-To: <06b501c3fcab$6f89e0e0$0303a8c0@marc2>
References: <A583F36C-689D-11D8-9105-000A95CEC334@nittin.net>
	<06b501c3fcab$6f89e0e0$0303a8c0@marc2>
Message-ID: <E1B11499-68A0-11D8-9105-000A95CEC334@nittin.net>


On Feb 26, 2004, at 3:59 PM, Marc Battyani wrote:

> Yes, you are probably using a stream for which file-position is not 
> defined.

How silly of me to not spot that.  Thanks.  Using the approach you 
describe
works fine.

Erik.




From david.cooper at genworks.com  Thu Feb 26 21:24:02 2004
From: david.cooper at genworks.com (David J Cooper Jr)
Date: Thu, 26 Feb 2004 16:24:02 -0500
Subject: [cl-pdf-devel] Problem with write-document with stream as
	opposedto pathname
In-Reply-To: <06b501c3fcab$6f89e0e0$0303a8c0@marc2>
References: <A583F36C-689D-11D8-9105-000A95CEC334@nittin.net>
	<06b501c3fcab$6f89e0e0$0303a8c0@marc2>
Message-ID: <16446.25586.351774.46397@mccarthy.genworks.com>


Hi Erik,

Marc B. writes:
 > 
 > If you want to generate a PDF in memory, to send in a web server
 > for instance, you need to write it in a with-output-to-string and
 > then write the string to you real stream.
 > 

And depending on what kind of stream you are talking about, it might
support something functionally equivalent to file-position which you
can use, for example the streams used by allegroserve on ACL support
excl::socket-bytes-written or something like that, which I have found
will work (and Franz/JKF confirms it should be stable to use) in lieu
of file-position. But the code I sent Marc for that did not make it
into cl-pdf because apparently it doesn't really offer much advantages
over writing to an intermediate string as Marc suggests above (or just
using a temporary file for that matter), and it adds the complication
of having to specialize for the type of stream (and God knows how many
stream varieties there might be out there). 

If you think it makes sense to re-open this issue let Marc and me
know.

 -dave




From erik at nittin.net  Thu Feb 26 21:25:26 2004
From: erik at nittin.net (Erik Enge)
Date: Thu, 26 Feb 2004 16:25:26 -0500
Subject: [cl-pdf-devel] Problem with write-document with stream as
	opposedto pathname
In-Reply-To: <16446.25586.351774.46397@mccarthy.genworks.com>
References: <A583F36C-689D-11D8-9105-000A95CEC334@nittin.net>
	<06b501c3fcab$6f89e0e0$0303a8c0@marc2>
	<16446.25586.351774.46397@mccarthy.genworks.com>
Message-ID: <4B78F6F4-68A2-11D8-9105-000A95CEC334@nittin.net>

On Feb 26, 2004, at 4:24 PM, David J Cooper Jr wrote:

> If you think it makes sense to re-open this issue let Marc and me
> know.

It would be nice to have it fixed but perhaps there is no solution that 
would work
well for all involved.  I've written a wrapper that writes to a 
temporary string.  Once
I'm working with larger documents I will probably write to a file to 
avoid eating to
much memory.  None of this takes me any significant time but a solution 
to the
original problem sounds like it will, so I say leave it as far as I'm 
concerned.

Erik.




From marc.battyani at fractalconcept.com  Thu Feb 26 21:28:54 2004
From: marc.battyani at fractalconcept.com (Marc Battyani)
Date: Thu, 26 Feb 2004 22:28:54 +0100
Subject: [cl-pdf-devel] Problem with write-document with stream
	asopposedto pathname
References: <A583F36C-689D-11D8-9105-000A95CEC334@nittin.net><06b501c3fcab$6f89e0e0$0303a8c0@marc2>
	<16446.25586.351774.46397@mccarthy.genworks.com>
Message-ID: <06ea01c3fcaf$8a86c3f0$0303a8c0@marc2>

"David J Cooper Jr" <david.cooper at genworks.com> writes:

Hi Dave,

>  > If you want to generate a PDF in memory, to send in a web server
>  > for instance, you need to write it in a with-output-to-string and
>  > then write the string to you real stream.
>  >
>
> And depending on what kind of stream you are talking about, it might
> support something functionally equivalent to file-position which you
> can use, for example the streams used by allegroserve on ACL support
> excl::socket-bytes-written or something like that, which I have found
> will work (and Franz/JKF confirms it should be stable to use) in lieu
> of file-position. But the code I sent Marc for that did not make it
> into cl-pdf because apparently it doesn't really offer much advantages
> over writing to an intermediate string as Marc suggests above (or just
> using a temporary file for that matter), and it adds the complication
> of having to specialize for the type of stream (and God knows how many
> stream varieties there might be out there).

Hmm... the most likely reason is probably that I was over busy as usual and
forgot it ;-)

>If you think it makes sense to re-open this issue let Marc and me
>know.

Yes. We can re-open the debate.

Marc