Subject: [Tools-discuss] PDF conversion problem

From: <[email-masked]>
Date: Wed, 21 May 2008 14:58:15 +0300

The txt to pdf conversion process has somehow failed for 
this draft:

http://tools.ietf.org/pdf/draft-ietf-pce-pcep-12.pdf

The txt version looks OK, so I can't immediately tell why
the PDF looks weird...

Best regards,
Pasi
_______________________________________________
Tools-discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tools-discuss

---

From: Lars Eggert <[email-masked]>
Date: Wed, 21 May 2008 16:30:45 +0300

> The txt version looks OK, so I can't immediately tell why

I'm guessing it's because it uses CR for newline. My review scripts  
had issues with the draft for that reason, too.

Lars

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 21 May 2008 16:38:05 +0200

Hi Pasi,

> The txt version looks OK, so I can't immediately tell why

Hah.  Same reason as for the rfcmarkup failure Brian pointed
out: The .txt file has Mac (\r) line endings.  I've added a
handling of this case to the pdf conversion script too.

	Henrik

---

From: <[email-masked]>
Date: Thu, 22 May 2008 22:46:36 +0300

> handling of this case to the pdf conversion script too.

Thanks for looking into this! 

(I suspected it might have something to do with line endings, and 
even tried doing search-replace for CR/LF/CFLF/whatever, but it 
seems Emacs hides this so well from the user that search-replace
for line endings doesn't always work perfectly.)

Best regards,
Pasi

---

From: Joe Touch <[email-masked]>
Date: Thu, 22 May 2008 13:20:47 -0700

[email-masked] wrote:
| Henrik Levkowetz wrote:
|
|> Hah.  Same reason as for the rfcmarkup failure Brian pointed
|> out: The .txt file has Mac (\r) line endings.  I've added a
|> handling of this case to the pdf conversion script too.
|
| Thanks for looking into this!
|
| (I suspected it might have something to do with line endings, and
| even tried doing search-replace for CR/LF/CFLF/whatever, but it
| seems Emacs hides this so well from the user that search-replace
| for line endings doesn't always work perfectly.)

Emacs often treats line endings locally, i.e., using the convention of
the OS on which it is installed. The only way to ensure the final .txt
file has the right EOL conventions (i.e., those required in RFCs, and
expected in IDs) is to perform post-processing substitution, e.g., via a
script.

Joe

---

From: Tony Hansen <[email-masked]>
Date: Thu, 22 May 2008 17:19:25 -0400

These are probably showing up now because of the I-D web interface to 
upload the drafts. When things were sent in via email, the 
canonicalization was probably performed by the secretariat. Perhaps you 
could check the I-D web interface to see if it could canonicalize things 
better?

	Tony Hansen
	[email-masked]

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 23 May 2008 01:47:12 +0200

Hi Tony,

> could check the I-D web interface to see if it could canonicalize things 

Mph.  I believe there were cases like this before, too -- I can certainly
remember running into documents with Mac line endings around 2002, and
there are both Unix-type and DOS-type line endings in documents from the
email-only submission period before the new submission tool.  I think that
running into this now is more an indication of an increasing number of
people using native Mac tools to produce documents.

As for doing line-ending normalization -- that may be a good thing to do,
or maybe not -- should an author be able to assume (and verify) that the
document in the archive is identically the same as the one submitted?

	Henrik

---

From: Tony Hansen <[email-masked]>
Date: Thu, 22 May 2008 22:26:19 -0400

There are several checks that aren't being done right now that could be 
done, such as looking for \r linebreaks and looking for non-ascii 
characters. Possibilities are to: a) silently accept such things, b) 
warn about but still accept, c) warn and query whether to accept as is 
or to convert, d) convert and tell the user it was converted, and e) 
silently converting. Right now it's (a). If the upload tool were to do 
(c) or (d), then there would be no confusion when the uploader checked 
the result against their input. Should the upload tool do something 
other than (a)? I'm sure there are many arguments either way.

	Tony Hansen
	[email-masked]

---

From: Joe Touch <[email-masked]>
Date: Thu, 22 May 2008 22:10:19 -0700

The script I developed for the Word template (URL below) might be useful 
in this regard; it catches non-ASCII characters, lines over length, etc. 
It would be fairly simple to update it to replace various linebreaks 
with the common form.

If that's of interest, let me know and I'll update the code...

Joe

http://www.isi.edu/touch/tools/2-Word-post-v2.0.pl