From marc.battyani at fractalconcept.com  Fri Dec 19 23:02:29 2003
From: marc.battyani at fractalconcept.com (Marc Battyani)
Date: Sat, 20 Dec 2003 00:02:29 +0100
Subject: [cl-pdf-devel] The cl-typesetting repository is online
Message-ID: <058701c3c684$2deceb30$0303a8c0@marc2>

The cl-pdf repository is online! :)

Here it is:
http://www.fractalconcept.com:8000/svn/public/cl-pdf/

It's a subversion repository. You can explore it with any browser but you
need to get subversion (subversion.tigris.org) to do a checkout.

I'm trying to setup a viewcvs for a more user friendly interface but it does
not work so far as I get an error traceback instead of a repository view...

If you reply to this mail, please reply only to the devel mailing list.

Marc




From crimsonf at cs.tu-berlin.de  Sun Dec 21 13:43:58 2003
From: crimsonf at cs.tu-berlin.de (Stephan Frank)
Date: Sun, 21 Dec 2003 14:43:58 +0100
Subject: [cl-pdf-devel] patch for small bug in t1-load
Message-ID: <3FE5A39E.AC536EB7@cs.tu-berlin.de>

Hallo,

the attached patch corrects a small bug in the array indexing while reading
pfb-files. The result was that the last part (which sall contain the 512 zeros
and cleartomark command) was actually read from a different location, thus
leading to incorrect data in the binary-data slot array.

regs,
Stephan
-------------- next part --------------
--- /home/root2/prj/cl-pdf/t1-font.lisp	Sat Dec 20 19:41:44 2003
+++ t1-font.lisp	Sun Dec 21 13:50:21 2003
@@ -41,7 +41,7 @@
     (setf (subseq binary-data length1 (+ length1 length2))
 	  (subseq data start2 (+ start2 length2)))
     (setf (subseq binary-data (+ length1 length2)(+ length1 length2 length3))
-	  (subseq data start2 (+ start3 length3)))
+	  (subseq data start3 (+ start3 length3)))
     (setf (binary-data t1fm) binary-data
 	  (length1 t1fm) length1
 	  (length2 t1fm) length2





From marc.battyani at fractalconcept.com  Sun Dec 21 21:43:11 2003
From: marc.battyani at fractalconcept.com (Marc Battyani)
Date: Sun, 21 Dec 2003 22:43:11 +0100
Subject: [cl-pdf-devel] patch for small bug in t1-load
References: <3FE5A39E.AC536EB7@cs.tu-berlin.de>
Message-ID: <014401c3c80b$82022540$0303a8c0@marc2>

"Stephan Frank" <crimsonf at cs.tu-berlin.de> writes
>
> the attached patch corrects a small bug in the array indexing while
reading
> pfb-files. The result was that the last part (which sall contain the 512
zeros
> and cleartomark command) was actually read from a different location, thus
> leading to incorrect data in the binary-data slot array.

Thanks!
Corrected. It's on the repository (with the improved barcode128 from Lars)

Marc




From jan at rychter.com  Fri Dec 26 10:33:56 2003
From: jan at rychter.com (Jan Rychter)
Date: Fri, 26 Dec 2003 02:33:56 -0800
Subject: [cl-pdf-devel] [local.cl-pdf.devel] CL-PDF won't compile on CMUCL
Message-ID: <m2d6abvpez.fsf@tnuctip.rychter.com>

Hmm, I had posted this message to local.cl-pdf.devel on
nntp.common-lisp.net, but it seems it hasn't made its way to the list,
so I'll repost.

--J.

-------------- next part --------------
An embedded message was scrubbed...
From: Jan Rychter <jan at rychter.com>
Subject: CL-PDF won't compile on CMUCL
Date: Sat, 20 Dec 2003 12:18:01 -0800
Size: 1600
URL: <https://mailman.common-lisp.net/pipermail/cl-pdf-devel/attachments/20031226/d0926241/attachment.mht>

From jan at rychter.com  Fri Dec 26 10:44:13 2003
From: jan at rychter.com (Jan Rychter)
Date: Fri, 26 Dec 2003 02:44:13 -0800
Subject: [local.cl-pdf.devel] Re: [cl-pdf-devel] The cl-typesetting
	repository is online
Message-ID: <m2zndfuade.fsf@tnuctip.rychter.com>

Another repost which seems not to have made it to the list via the NNTP
gateway:

Hi,

I've just tried cl-pdf and it looks and works great! I must say I'm
rather impressed.

So now for the questions: is there a way to make it work with Unicode
text? I've tried some Unicode (UTF-8 encoded) characters, but didn't get
very good results. It seems that the only that passes through correctly
is 8-bit ISO-8859-1. And I also need ISO-8859-2 and Japanese :-)

Now, I'm sure it's a thorny issue, having to do with fonts, encodings,
and CL implementation's support for Unicode, but I thought I'd ask what
the major obstacles are.

BTW, I'm trying cl-pdf and cl-typesetting out of frustration with LaTeX.

--J.



From marc.battyani at fractalconcept.com  Fri Dec 26 11:02:18 2003
From: marc.battyani at fractalconcept.com (Marc Battyani)
Date: Fri, 26 Dec 2003 12:02:18 +0100
Subject: [cl-pdf-devel] Re: CL-PDF won't compile on CMUCL
References: <m2hdzv451i.fsf@tnuctip.rychter.com>
Message-ID: <009b01c3cb9f$d0cf9710$0303a8c0@marc2>


> I'm not sure if that's a CL-PDF bug or a CMUCL bug, but as it is, CL-PDF
> won't parse the font metrics correctly. The parsing fails with a
> parse-error condition in get-afm-number.
>
> It fails because:
>
> PDF> (parse-integer "FontBBox -113 -250 749 801" :start 8 :junk-allowed t)
> -113
> 14
> PDF>
>
> You'll notice that it has skipped over the whitespace past the first
> number. This confuses the logic in get-afm-number, which doesn't expect
> that.

It's a CMUCL problem but it has been corrected (thanks to Adam Warner) so
try a more recent version or an older one before they changed the
parse-integer behavior) The (rather hot) debate can be followed on the CMUCL
dev mailing list.

> To quote the hyperspec:
>
>   parse-integer expects an optional sign (+ or -) followed by a a
>   non-empty sequence of digits to be interpreted in the specified
>   radix. Optional leading and trailing whitespace[1] is ignored.
>
> I'm afraid that 'ignored' can mean both "parsed" and "left unparsed", so
> I guess get-afm-number should be ready for that.

There has been some debate on this issue. Both interpretations are correct
w.r.t. the standard. But all the implentations including the old CMUCL
choosed to stop at the first whitespace.

Marc




From marc.battyani at fractalconcept.com  Fri Dec 26 11:02:21 2003
From: marc.battyani at fractalconcept.com (Marc Battyani)
Date: Fri, 26 Dec 2003 12:02:21 +0100
Subject: [local.cl-pdf.devel] Re: [cl-pdf-devel] The cl-pdf repository is
	online
References: <m2zndfuade.fsf@tnuctip.rychter.com>
Message-ID: <00ce01c3cb9f$e5cde360$0303a8c0@marc2>

> I've just tried cl-pdf and it looks and works great! I must say I'm
> rather impressed.

Thanks!

> So now for the questions: is there a way to make it work with Unicode
> text? I've tried some Unicode (UTF-8 encoded) characters, but didn't get
> very good results. It seems that the only that passes through correctly
> is 8-bit ISO-8859-1. And I also need ISO-8859-2 and Japanese :-)

You can create all the the 8 bits encoding you want. (Please send them if
you make useful ones)
But there is no support yet for multibytes encodings.

> Now, I'm sure it's a thorny issue, having to do with fonts, encodings,
> and CL implementation's support for Unicode, but I thought I'd ask what
> the major obstacles are.

No major obstacles IMO. It's well documented in the PDF reference from
adobe.

> BTW, I'm trying cl-pdf and cl-typesetting out of frustration with LaTeX.

I started cl-typesetting exactly for the same reason. cl-typesetting can
already do lots of things than TeX can't do, but it is still missing all the
upper layers to be usable as a general purpose formatter. The good news is
that as it's written in Common Lisp, it won't take years of development to
do this. If we work on it that is ;-)

Marc




From jan at rychter.com  Sat Dec 27 00:26:45 2003
From: jan at rychter.com (Jan Rychter)
Date: Fri, 26 Dec 2003 16:26:45 -0800
Subject: [cl-pdf-devel] Re: CL-PDF won't compile on CMUCL
References: <m2hdzv451i.fsf@tnuctip.rychter.com>
	<009b01c3cb9f$d0cf9710$0303a8c0@marc2>
Message-ID: <m2wu8jrtq2.fsf@tnuctip.rychter.com>

[...]
 >> You'll notice that it has skipped over the whitespace past the first
 >> number. This confuses the logic in get-afm-number, which doesn't
 >> expect that.

>>>>> "Marc" == Marc Battyani <marc.battyani at fractalconcept.com> writes:
 Marc> It's a CMUCL problem but it has been corrected (thanks to Adam
 Marc> Warner) so try a more recent version or an older one before they
 Marc> changed the parse-integer behavior) The (rather hot) debate can
 Marc> be followed on the CMUCL dev mailing list.

 >> To quote the hyperspec:
 >>
 >> parse-integer expects an optional sign (+ or -) followed by a a
 >> non-empty sequence of digits to be interpreted in the specified
 >> radix. Optional leading and trailing whitespace[1] is ignored.
 >>
 >> I'm afraid that 'ignored' can mean both "parsed" and "left
 >> unparsed", so I guess get-afm-number should be ready for that.

 Marc> There has been some debate on this issue. Both interpretations
 Marc> are correct w.r.t. the standard. But all the implentations
 Marc> including the old CMUCL choosed to stop at the first whitespace.

Hmm -- not that it's a particularly important issue, but wouldn't it be
the CL Way (tm) to try to write code so that it works with all
implementations that are correct w.r.t. the standard?

But, as I said, nothing terribly important. I have to upgrade anyway.

best regards,
--Jan