From ch-lisp at bobobeach.com Wed Oct 3 23:26:36 2007 From: ch-lisp at bobobeach.com (Cyrus Harmon) Date: Wed, 3 Oct 2007 16:26:36 -0700 Subject: [cl-typesetting-devel] leading/line-spacing and text style Message-ID: <3D5039AD-A220-4AFF-BE56-902A9CF09EC5@bobobeach.com> Is there a way to set the vertical spacing between lines on a per- style basis? How about adding a line-spacing (or highjacking the existing leading) to the style class? Looks (yeah, right) trivial enough, but I figured I'd ask if there was a better way first. Thanks, Cyrus From divanov at aha.ru Thu Oct 4 06:09:44 2007 From: divanov at aha.ru (Dmitriy Ivanov) Date: Thu, 4 Oct 2007 10:09:44 +0400 Subject: [cl-typesetting-devel] leading/line-spacing and text style References: <3D5039AD-A220-4AFF-BE56-902A9CF09EC5@bobobeach.com> Message-ID: <000d01c8064d$36ccf7b0$8100a8c0@digo> Hello Cyrus, | Is there a way to set the vertical spacing between lines on a per- | style basis? How about adding a line-spacing (or highjacking the | existing leading) to the style class? Looks (yeah, right) trivial | enough, but I figured I'd ask if there was a better way first. IMHO, incorporating *leading-ratio* into the text-style class is quite reasonable. The use-style method would look like the following: (defmethod use-style ((style text-style)) (macrolet ((%use-style% (name var) `(let ((style (,name style))) (when style (setf ,var style))))) ... (%use-style% leading-ratio *leading-ratio*)) (when (and (leading-ratio style) (or (font style)(font-size style))) (setf *leading* (* *font-size* *leading-ratio*)))) The other xxx-style methods should also reset the value of *leading* appropriately. Could you experiment, please? -- Sincerely, Dmitriy Ivanov lisp.ystok.ru From ch-lisp at bobobeach.com Thu Oct 4 14:19:25 2007 From: ch-lisp at bobobeach.com (Cyrus Harmon) Date: Thu, 4 Oct 2007 07:19:25 -0700 Subject: [cl-typesetting-devel] leading/line-spacing and text style In-Reply-To: <000d01c8064d$36ccf7b0$8100a8c0@digo> References: <3D5039AD-A220-4AFF-BE56-902A9CF09EC5@bobobeach.com> <000d01c8064d$36ccf7b0$8100a8c0@digo> Message-ID: <55F70886-BF53-411F-962E-71F78F589104@bobobeach.com> Yes, this was my thinking as well. I'll check it out. Thanks, Cyrus On Oct 3, 2007, at 11:09 PM, Dmitriy Ivanov wrote: > Hello Cyrus, > > | Is there a way to set the vertical spacing between lines on a per- > | style basis? How about adding a line-spacing (or highjacking the > | existing leading) to the style class? Looks (yeah, right) trivial > | enough, but I figured I'd ask if there was a better way first. > > IMHO, incorporating *leading-ratio* into the text-style class is quite > reasonable. The use-style method would look like the following: > > (defmethod use-style ((style text-style)) > (macrolet ((%use-style% (name var) > `(let ((style (,name style))) > (when style (setf ,var style))))) > ... > (%use-style% leading-ratio *leading-ratio*)) > (when (and (leading-ratio style) (or (font style)(font-size style))) > (setf *leading* (* *font-size* *leading-ratio*)))) > > The other xxx-style methods should also reset the value of *leading* > appropriately. Could you experiment, please? > -- > Sincerely, > Dmitriy Ivanov > lisp.ystok.ru > From ch-lisp at bobobeach.com Thu Oct 4 21:50:28 2007 From: ch-lisp at bobobeach.com (Cyrus Harmon) Date: Thu, 4 Oct 2007 14:50:28 -0700 Subject: [cl-typesetting-devel] leading/line-spacing and text style In-Reply-To: <55F70886-BF53-411F-962E-71F78F589104@bobobeach.com> References: <3D5039AD-A220-4AFF-BE56-902A9CF09EC5@bobobeach.com> <000d01c8064d$36ccf7b0$8100a8c0@digo> <55F70886-BF53-411F-962E-71F78F589104@bobobeach.com> Message-ID: <2321BBC1-5C23-461D-A951-CB4279E058C6@bobobeach.com> The following patch adds leading-ratio to the style. Cyrus -------------- next part -------------- A non-text attachment was scrubbed... Name: cl-typesetting-leading-ratio-style.diff Type: application/octet-stream Size: 4613 bytes Desc: not available URL: -------------- next part -------------- From divanov at aha.ru Fri Oct 5 13:11:32 2007 From: divanov at aha.ru (Dmitriy Ivanov) Date: Fri, 5 Oct 2007 17:11:32 +0400 Subject: [cl-typesetting-devel] leading/line-spacing and text style References: <3D5039AD-A220-4AFF-BE56-902A9CF09EC5@bobobeach.com><000d01c8064d$36ccf7b0$8100a8c0@digo><55F70886-BF53-411F-962E-71F78F589104@bobobeach.com> <2321BBC1-5C23-461D-A951-CB4279E058C6@bobobeach.com> Message-ID: <008b01c80751$49f186d0$8100a8c0@digo> Hello Cyrus, | The following patch adds leading-ratio to the style. Thanks Cyrus. Slightly modified, works for me. I have just committed specials.lisp and typo.lisp to the repository. Please update and test. I also suggest avoiding the heavy decoration feature via the :no-typeset-decoration feature. For example: (defclass text-style (style) ((font :accessor font :initform nil) (font-size :accessor font-size :initarg :font-size :initform nil) (text-x-scale :accessor text-x-scale :initarg :text-x-scale :initform nil) (color :accessor color :initarg :color :initform nil) (background-color :accessor background-color :initarg :background-color :initform nil) (h-align :accessor h-align :initarg :h-align :initform nil) (left-margin :accessor left-margin :initarg :left-margin :initform nil) (right-margin :accessor right-margin :initarg :right-margin :initform nil) #-no-typeset-decoration (pre-decoration :accessor pre-decoration :initarg :pre-decoration :initform nil) #-no-typeset-decoration (post-decoration :accessor post-decoration :initarg :post-decoration :initform nil) (leading-ratio :accessor leading-ratio :initarg :leading-ratio :initform nil))) and so on. What do other folks think? -- Sincerely, Dmitriy Ivanov lisp.ystok.ru From marc.battyani at fractalconcept.com Fri Oct 5 14:30:30 2007 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Fri, 05 Oct 2007 16:30:30 +0200 Subject: [cl-typesetting-devel] leading/line-spacing and text style In-Reply-To: <008b01c80751$49f186d0$8100a8c0@digo> References: <3D5039AD-A220-4AFF-BE56-902A9CF09EC5@bobobeach.com><000d01c8064d$36ccf7b0$8100a8c0@digo><55F70886-BF53-411F-962E-71F78F589104@bobobeach.com> <2321BBC1-5C23-461D-A951-CB4279E058C6@bobobeach.com> <008b01c80751$49f186d0$8100a8c0@digo> Message-ID: <47064A86.4060704@fractalconcept.com> Dmitriy Ivanov wrote: > Hello Cyrus, > > | The following patch adds leading-ratio to the style. > > Thanks Cyrus. Slightly modified, works for me. > I have just committed specials.lisp and typo.lisp to the repository. > Please update and test. > > I also suggest avoiding the heavy decoration feature via the > :no-typeset-decoration feature. For example: > > (defclass text-style (style) > ((font :accessor font :initform nil) > (font-size :accessor font-size :initarg :font-size :initform nil) > (text-x-scale :accessor text-x-scale :initarg :text-x-scale :initform > nil) > (color :accessor color :initarg :color :initform nil) > (background-color :accessor background-color :initarg :background-color > :initform nil) > (h-align :accessor h-align :initarg :h-align :initform nil) > (left-margin :accessor left-margin :initarg :left-margin :initform nil) > (right-margin :accessor right-margin :initarg :right-margin :initform > nil) > #-no-typeset-decoration (pre-decoration :accessor pre-decoration :initarg > :pre-decoration :initform nil) > #-no-typeset-decoration (post-decoration :accessor post-decoration > :initarg :post-decoration :initform nil) > (leading-ratio :accessor leading-ratio :initarg :leading-ratio :initform > nil))) > > and so on. > > What do other folks think? > It's ok for me. but maybe it's better to have some run time switch to decide on a per typesetting engine if decorations are needed or not. Otherwise if an application has at least one document which uses it, the other documents will be impacted. Marc From divanov at aha.ru Sat Oct 6 09:20:26 2007 From: divanov at aha.ru (Dmitriy Ivanov) Date: Sat, 6 Oct 2007 13:20:26 +0400 Subject: [cl-typesetting-devel] leading/line-spacing and text style References: <3D5039AD-A220-4AFF-BE56-902A9CF09EC5@bobobeach.com><000d01c8064d$36ccf7b0$8100a8c0@digo><55F70886-BF53-411F-962E-71F78F589104@bobobeach.com> <2321BBC1-5C23-461D-A951-CB4279E058C6@bobobeach.com> <008b01c80751$49f186d0$8100a8c0@digo> <47064A86.4060704@fractalconcept.com> Message-ID: <000001c807fc$8ea2dc10$8100a8c0@digo> "Marc Battyani" wrote: |> I also suggest avoiding the heavy decoration feature via the |> :no-typeset-decoration feature. For example: |> |...snip...| |> #-no-typeset-decoration |> (pre-decoration :accessor pre-decoration :initarg :pre-decoration |> :initform nil) |> #-no-typeset-decoration |> (post-decoration :accessor post-decrationon :initarg :post-decoration |> :initform nil) | | It's ok for me. but maybe it's better to have some run | time switch to decide on a per typesetting engine if decorations | are needed or not. | Otherwise if an application has at least one document | which uses it, the other documents will be impacted. The before and after methods on stroke for char-boxes both use a kind of run-time switch. Nevertheless, they are slowing down things considerably. The only solution I can imagine is setting :no-typeset-decoration at compile-time. It should be established only for the applications that do need decoration. The net problem, separating binaries, i.e. fasl-files, is easily solved with LispWorks defsystem but, AFAIK, is hardly treatable by means of ASDF. -- Sincerely, Dmitriy Ivanov lisp.ystok.ru From levente.meszaros at gmail.com Tue Oct 9 08:05:33 2007 From: levente.meszaros at gmail.com (=?ISO-8859-1?Q?Levente_M=E9sz=E1ros?=) Date: Tue, 9 Oct 2007 10:05:33 +0200 Subject: [cl-typesetting-devel] Unicode issue In-Reply-To: References: Message-ID: Hi, May I ask some help? I have attached an example which results in a wrong pdf (see image). Both evince and acroread under feisty ubuntu displays wrong characters (i.e. boxes). AFAICT the problem is related to unicode encoding, escaping in pdf (for parenthesis) and external formats. I'm using SBCL and the latest cl-pdf, cl-typesetting versions. The example uses a unicode font and simply puts a string into the output document which contains #\Space #\( #\) and a few other characters. Both parenthesis and space are needed to produce the wrong pdf. If you don't have the font you may download it from: http://files-upload.com/files/548738/FreeSerif.tar And if you wish to download the resulting pdf go to: http://files-upload.com/files/548742/hello.pdf Sorry about the 30 seconds... Cheers, levy -- There's no perfectoin -------------- next part -------------- A non-text attachment was scrubbed... Name: test.lisp Type: application/x-extension-lisp Size: 578 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot.png Type: image/png Size: 24871 bytes Desc: not available URL: From marc.battyani at fractalconcept.com Wed Oct 10 22:07:44 2007 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Thu, 11 Oct 2007 00:07:44 +0200 Subject: [cl-typesetting-devel] Re: [cl-pdf-devel] Unicode issue In-Reply-To: References: Message-ID: <470D4D30.9090907@fractalconcept.com> Levente M?sz?ros wrote: > Hi, > > May I ask some help? > > I have attached an example which results in a wrong pdf (see image). Both evince > and acroread under feisty ubuntu displays wrong characters (i.e. > boxes). > > AFAICT the problem is related to unicode encoding, escaping in pdf > (for parenthesis) and external formats. I'm using SBCL and the latest > cl-pdf, cl-typesetting versions. > > The example uses a unicode font and simply puts a string into the > output document which contains #\Space #\( #\) and a few other > characters. Both parenthesis and space are needed to produce the wrong > pdf. > > If you don't have the font you may download it from: > http://files-upload.com/files/548738/FreeSerif.tar > > And if you wish to download the resulting pdf go to: > http://files-upload.com/files/548742/hello.pdf > > Sorry about the 30 seconds... > Unfortunately, the unicode integration is still in an alpha state as I've never found the time to continue it :( I will look at your example to see if I can make a fix for it. Cheers, Marc From levente.meszaros at gmail.com Thu Oct 11 08:15:07 2007 From: levente.meszaros at gmail.com (=?ISO-8859-1?Q?Levente_M=E9sz=E1ros?=) Date: Thu, 11 Oct 2007 10:15:07 +0200 Subject: [cl-typesetting-devel] Re: [cl-pdf-devel] Unicode issue In-Reply-To: <470D4D30.9090907@fractalconcept.com> References: <470D4D30.9090907@fractalconcept.com> Message-ID: Hi Marc, We have looked at this issue more deeply and got to the point: (defmethod write-to-page ((string string) (encoding unicode-encoding) &optional escape) (declare (ignore escape)) (loop for char across string for code = (char-code char) do (write-char (code-char (ldb (byte 8 8) code)) *page-stream*) (write-char (code-char (ldb (byte 8 0) code)) *page-stream*))) This method does not seem to handle escaping unbalanced parenthesis. I have tried several ways to fix this. Escaping parenthesis by a backslash either in unicode or latin-1, etc but without success. I was looking at the resulting pdf in binary form and saw that the string is split into two parts separated by a horizontal spacing. This causes the unbalanced parenthesis to be present in both parts and thus displaying those boxes. Unfortunately I don't know much about pdf format. I had a look at the horrible thousand pages spec, but was unable to find out how to solve this. A workaround for this problem is to switch to a non-unicode font when displaying a parenthesis, because cl-pdf will write them in separate text chunk wihtout unicode encoding and with proper escaping. This is not so nice but works. levy -- There's no perfectoin From gwking at metabang.com Sat Oct 13 01:42:26 2007 From: gwking at metabang.com (Gary King) Date: Fri, 12 Oct 2007 21:42:26 -0400 Subject: [cl-typesetting-devel] Paragraph In-Reply-To: <470D4D30.9090907@fractalconcept.com> References: <470D4D30.9090907@fractalconcept.com> Message-ID: <8530AC94-F95D-45A4-98E6-838874CB5950@metabang.com> The paragraph macro doesn't evaluate its arguments which seems to make it hard to use programatically. I've hardly scratched the surface of CL-PDF and CL-Typesetting but the following change would allow the paragraph macro to take either a property list (unevaluated) or a symbol (evaluated) as argument. (Another, perhaps better, alternative would be to have two macros -- paragraph and paragraph*? -- one of which didn't evaluate its arguments and one of which did... Am I missing something? Is there another way to modify the styles "programmatically". thanks, (defmacro paragraph ((&rest style) &body body) (print (list :x style (and (null (rest style)) (symbolp (first style))))) (with-gensyms (gstyle new-style restore-style first-indent top-margin bottom-margin first-line-indent) `(let* ((,gstyle ,@(if (and (null (rest style)) (symbolp (first style))) style `(', at style))) (,top-margin (getf ,gstyle :top-margin 0)) (,bottom-margin (getf ,gstyle :bottom-margin 0)) (,first-line-indent (getf ,gstyle :first-line-indent 0)) (,new-style (apply #'make-instance 'text-style ,gstyle)) (,restore-style (make-restore-style ,new-style)) (,first-indent ,first-line-indent)) (add-box ,new-style) (use-style ,new-style) (add-box (make-instance 'v-spacing :dy ,top-margin)) (unless (zerop ,first-indent) (add-box (make-instance 'h-spacing :dx ,first-indent))) ,@(mapcar 'insert-stuff body) (unless (eq (first (boxes-tail *content*)) :eol) (add-box :eol)) (add-box (make-instance 'v-spacing :dy ,bottom-margin)) (add-box ,restore-style) (use-style ,restore-style)))) -- Gary Warren King, metabang.com Cell: (413) 559 8738 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM From divanov at aha.ru Sun Oct 14 08:50:14 2007 From: divanov at aha.ru (Dmitriy Ivanov) Date: Sun, 14 Oct 2007 12:50:14 +0400 Subject: [cl-typesetting-devel] Re: [cl-pdf-devel] Paragraph References: <470D4D30.9090907@fractalconcept.com> <8530AC94-F95D-45A4-98E6-838874CB5950@metabang.com> Message-ID: <000001c80e3f$4e2a4260$8100a8c0@digo> Hello Gary, | The paragraph macro doesn't evaluate its arguments which seems to | make it hard to use programatically. I've hardly scratched the | surface of CL-PDF and CL-Typesetting but the following change would | allow the paragraph macro to take either a property list | (unevaluated) or a symbol (evaluated) as argument. (Another, perhaps | better, alternative would be to have two macros -- paragraph and | paragraph*? -- one of which didn't evaluate its arguments and one of | which did... Am I missing something? Is there another way to modify | the styles "programmatically". I am afraid the above is not true. The paragraph macro does evaluate its arguments. To provide "precompiled" styles, I would suggest the following: 1. Add the new class, e.g. (defclass paragraph-style (text-style) ((top-margin) (bottom-margin) (first-line-indent))) (I would also vote for moving the left-margin and right-margin slots there.) 2. Treat the :style property indicator in the paragraph macro specially, e.g. (defmacro paragraph ((&rest plist &key style) &body body) (with-gensyms (new-style restore-style first-indent) ... `(let* ((,new-style ,(or style `,(make-instance 'paragraph-style , at plist))) ...) ...))) 3. Rename with-style and set-style to with-style-plist and set-style-plist correspondingly. 4. Redefine with-style and set-style to accept a style instance as an argument instead of a plist. -- Sincerely, Dmitriy Ivanov lisp.ystok.ru From marc.battyani at fractalconcept.com Sun Oct 14 15:52:15 2007 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Sun, 14 Oct 2007 17:52:15 +0200 Subject: [cl-typesetting-devel] Re: [cl-pdf-devel] Unicode issue In-Reply-To: References: <470D4D30.9090907@fractalconcept.com> Message-ID: <47123B2F.5050403@fractalconcept.com> Levente M?sz?ros wrote: > Hi Marc, > > We have looked at this issue more deeply and got to the point: > > (defmethod write-to-page ((string string) (encoding unicode-encoding) > &optional escape) > (declare (ignore escape)) > (loop for char across string > for code = (char-code char) > do (write-char (code-char (ldb (byte 8 8) code)) *page-stream*) > (write-char (code-char (ldb (byte 8 0) code)) *page-stream*))) > > This method does not seem to handle escaping unbalanced parenthesis. I > have tried several ways to fix this. Escaping parenthesis by a > backslash either in unicode or latin-1, etc but without success. I was > looking at the resulting pdf in binary form and saw that the string is > split into two parts separated by a horizontal spacing. This causes > the unbalanced parenthesis to be present in both parts and thus > displaying those boxes. > > Unfortunately I don't know much about pdf format. I had a look at the > horrible thousand pages spec, but was unable to find out how to solve > this. > > A workaround for this problem is to switch to a non-unicode font when > displaying a parenthesis, because cl-pdf will write them in separate > text chunk wihtout unicode encoding and with proper escaping. This is > not so nice but works. > OK BTW, sorry for the long delay for the reply. :( This function uses the normal string representation which is not very suitable for unicode strings. The hexadecimal string encodings is more bullet proof for this. So I modified cl-pdf so to use that hexadecimal encoding for unicode fonts. Seems to work for me now. Can you test it? BTW it's probably possible to use the normal string encoding with unicode fonts, it's just that the escape sequence is probably needed for the stream octets rather than the string characters. Maybe somebody has some time to look at this. Marc From levente.meszaros at gmail.com Mon Oct 15 10:03:24 2007 From: levente.meszaros at gmail.com (=?ISO-8859-1?Q?Levente_M=E9sz=E1ros?=) Date: Mon, 15 Oct 2007 12:03:24 +0200 Subject: [cl-typesetting-devel] Re: [cl-pdf-devel] Unicode issue In-Reply-To: <47123B2F.5050403@fractalconcept.com> References: <470D4D30.9090907@fractalconcept.com> <47123B2F.5050403@fractalconcept.com> Message-ID: > Seems to work for me now. Can you test it? Works fine here, nice to hear from you Marc. > BTW it's probably possible to use the normal string encoding with > unicode fonts, it's just that the escape sequence is probably needed for > the stream octets rather than the string characters. Maybe somebody has > some time to look at this. I did take a look at but could not figure out. It would result in smaller pdfs, so it's worth doing but not a priority for us now. As a side effect now we can turn on compression for unicode pdf-s too, since it's not going to mix up encoding anymore. Thanks again, levy -- There's no perfectoin