Alexander E. Patrakov wrote these words on 12/27/05 23:04 CST:

> OK, I will make this a per-package note. Let me start with two packages, 
> please tell if the new proposed form is acceptable. If there are no 
> objections for UnZip, I will continue with other packages. The style of 
> the two packages below is intentionally different, only UnZip is meant 
> to be acceptable.

It is more than acceptable. It is beautiful technical prose. :-)

I have some thoughts about the whole idea of problematic UTF-8
packages, and I'd like your feedback on the ideas.

1) I was wrong about this requiring just a note, however, I
do feel a Warning is too strong also. I believe the perfect
compromise is using the <caution> tags. Nice yellow icon with
the exclamation point will catch the readers attention, yet
won't scare them off.

2) I now feel, because of the possibility of long technical
explanations, that it may be best to create a *separate* page
in the book, probably in Chapter 2 "Important Information", where
all the information about UTF-8 issues will be presented. All
the packages with issues will be presented here, each with its
own section identified with an <id> tag.

  a) The <caution> tag will still be on the respective page
  (UnZip, for example) and in this caution box will be a note
  with text similar to this:
  "This package is known to have issues if used in UTF-8 locales.
  For complete information, see  <xref linkend=>."

  b) The xref link will be to the UTF-8 issues page to the spot
  on the page for that exact text (using the "id" tags).

  c) I'm suggesting this as I believe the text about the UTF-8
  issues (if UnZip will be a representative example) is very
  long, will take up much space on the page, so much so that I
  think it will distract from the real material.

  d) For readers that don't care about UTF-8 issues, they can
  simply skip right by the Caution and continue. For readers who
  might be affected by the issues, certainly they'll follow the
  link and read the relevant material.

  e) Having all the UTF-8 issues centralized is good because if
  readers stumble upon this page, or takes one of the links to
  it, she'll then at that point be able to see all of the packages
  that have UTF-8 issues.

What do you think of this idea?


> I want your version of MC breakage description, 

Alex, there's probably nobody more qualified to write and describe
these issues. Your work is always of impeccable quality. I will
certainly try and help however I can. Do know that I cannot
reproduce these issues, and can only go on what you say, so it is
difficult for me.

Anyway, your comments on my suggestions how to handle the whole
UTF-8 issue would be appreciated. If you are positive about the
idea, I'll start immediately with the UnZip material.

-- 
Randy

rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3]
[GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686]
07:30:00 up 94 days, 16:54, 3 users, load average: 0.12, 0.16, 0.36
-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Reply via email to