RFE/RFC?:desired enhancement or 'already in there'? backups fonts for unmapped chars, families and Unicode blocks

classic Classic list List threaded Threaded
41 messages Options
123
Reply | Threaded
Open this post in threaded view
|

RFE/RFC?:desired enhancement or 'already in there'? backups fonts for unmapped chars, families and Unicode blocks

L. A. Walsh
RFE/RFC?:desired enhancement or 'already in there'? backups fonts for unmapped chars, families and Unicode blocks

Current problem:

(If you can't read this in HTML, you are deprived, and maybe, in the internet "3rd world", my condolences, as documents structure can't be properly represented in plain text, (unless your eyes have built-in XML/HTML or LaTeX code interpretation).

I've been trying to use better fonts and Unicode usage in my work (email, web pages, etc).  Of source, using Vim for just about everything (Does anyone know of a Thunderbird extension to automatically allow or call Vim to edit dir Thunderbird composition --- especially when one switches into 'Source(HTML)' mode...that editor *sucks* big-time..., but I digress.

I really am getting discouraged with the fonts available to me in monospaced fonts.

The only ones that look halfway readable are the Lucida family...followed by the Monospace 821.  .  New courier is just too thin.  Consolas isn't much better (a free font
download from MS, no less!)

    My font (in Truetype or OpenType) list has: several monospace fonts that specialize in the CJK  block, but non of those have great latin rendering and little coverage for Unicode blocks outside of the CJK blocks  those include:  (all the 'che variations seem to be the monospace ones) Batang, Doton Gulim Gunshuh, Jurchen Krystoid, MingLiU, MS Gothic, and MS Mincho.

The few that specialize in the Hebrew block, don't help me much: Fixed Miriam Transparent, Rod (& Rod Transparent), neither the one in Arabic (Simplified Arabic Fixed).  Non Unicode, symbol-only or raster fonts I won't mention in this listing.

Among the Unicode fonts, ones that have western font and western usage (symbols, etc) coverage , I list the number of Unicode blocks they cover as well as total characters in the font.  There are only 9 choices on my system, (though I describe one's coverage in detail with the lament that for some unknown reason, it isn't offered on the list, though it's 2nd plane 'cousin' is):

Name Blocks
Total-Chars   Comments
Andale Mono 22, 654

Bitstream Vera Sans Mono 12 256

Code2002 11 (CJK)
20,409   [sic/broken] this entry is broken

 

Note on Code2002:  It is the 3rd font in a 3 font series (Code2000, Code2001, and Code2002, all available for very low (as low as $0) price (shareware(non-crippled)) or freeware from http://www.code2000.net/). All are monospaced fonts. Code2000 was for our first 64K (MS's initial UCS-2 set for NT4) code plane.  When discovering 64K was no where near enough, more planes were added.  Code2001 is for Unicode Plane 1 and Code2002 is for plane 2.  Code 2000 -- the one that contains the latin characters doesn't show up as a choice, though it should -- they are all monospaced fonts;  Code2002 is useless for Latin fonts (has 95/128 of Basic, 1/128 of Ext-A, 1/208 of Ext-B 96/129 of Supplement-1, 1/80 of Spacing modifiers), vs "Code2000" which is designed to cover Plane 1 (first 64K),  which has 118 blocks and 54,068 chars).  It's not the most excellent looking (at 10242 points per char) it was designed with less resolution than MS's TTF fonts, like Lucida Console (@40962 ppc), BUT on the list of unicode fonts it's pretty darn good, and probably 2nd best after the top MS fonts (which have no where near the coverage -- it could be there's a tradeoff -- 4x4 or 16 times the resolution/char OR 54,068/663 = 81 times the coverage.

Of Latin usable chars, it has

  • all alphabetic presentation forms (58/58),
  • all arrows(112/112),
  • 95/128 of Basic Latin
  • all the Box drawing chars (128/128),
  • all Braille Patterns (256/256)
  • Combining diacriticals [like accents over chars) (112/112)
  • Combining for symbols (28/33) & supplement (13/41) & half marks(4/7)
  • control pics (symbols for the control characters below like "LF", TAB, CR"; 39/39);
  • 22/22 Currency symbols 174/174 Dingbats (all the special symbols designed by the designer "Zapf" last century)
  • 160/160 Enclosed alpha numerics
  • 106/107 General Puncuntuation
  • Greek symbols (2 blocks: 134/134+233/233)
  • halfwidth and full width forms (including !!colon!! that you can put in Windows (and linux) filenames: "file:foobar" (the character after 'file' and before 'foobar' is a single character composed of a colon and an embeded space.  It is legal in WinXP and above and linux  (and likely MAC) if you are using UTF-8.  It displays as a colon followed by a space!  So in a linux shell, you don't need to quote it -- it's not a space breaking character!

  • Then 6 Latin extended blocks "extended additional(256/25), A(128/128) B(208/208) C(29/29), D(114/114) & Latin-1 Supple(96/128)
  • Letter like symbols (like the C for Centigrade, or 'c/o' as a single char(80/80)
  • Mathematical Operators (256/256), Math symbols A (44/44), B(128/128)
  • Misc Symbols(183/191), Misc Sym+Arrows(82/82)
  • Misc Technical (228/232)
  • Number Forms (Roman numberals, fractions, et al) (54/54)
  • OCR (11/11)
  • Phonetic Extensions (128/128) & Supplements (64/64) (for pronuncation)
  • Spacing modifiers (including small spaces, the ever used &nbsp, (80/80)
  • Superscripts/subscripts (29/34)
  • Supplemental: Arrows A(16/16), Arrows B(128/128), Math(256/256) and Punctuation(49/49)
AND a bunch of foreign languages symbols ... but due to some bug, somewhere, and I don't think it is in Vim, since it is also in 'SecureCRT' (http://www.vandyke.com/products/securecrt/index.html), my Win->lin TTY program (that also supports UTF-8) has same font list as Vim and includes Code2002, but not Code 2000. Grrr! It seems like it's some bit not set right somewhere, so Windows isn't displaying the correct font list...or, it's JAMSB (Just another MicroSoft Bug) :-).

Continuing, a few last fonts...other fonts:

Name
blocks,chars  Comments
Courier New (28, 1230) but this font isn't easy on the eyes
DejaVu Sans Mono (39, 2900)
Everson Mono (67, 6391) 2nd best coverage, poor readability)
Lucida Console (22, 663) Best readable (IMO)
Lucida SansTypewriter (12, 240) fairly good read, taller/thinner



Desired Enhancement 1:   Font Lists, acting as fall-through backups for missing chars


I'd first like something like the 'guifontset' option work to automatically use successive entries on the font list as 'fallback' entries if the character being displayed isn't in the currently selected font.  That way, I can have my primary, and a backup, and, possibly a catchall, though I could see this being also used to support multiple families -- like if I write in Cherokee, I could have a Cherokee font in my list, and when I typed in that font, Gvim  would automatically fall through the fonts that don't have those chars mapped,
and would display chars from a font with those chars mapped.

I would expect that the fonts would be examined once, on startup, with maybe a 'cache-file' being created, of the mappings (if the examination process takes any appreciable length of time).  Once examined, the mappings could be used automatically at runtime.


Desired Enhancement 2:   Support of Font Families

If this were supported, one could actually specify what font to use for what named Unicode block. 
The names of the blocks are published and can be tested.  Perl has had this support for a few years, for example (man perlunicode).  All of the information on the ranges and glyph names can be found on "http://www.unicode.org" . 

The data files are in the directory "http://www.unicode.org/Public/UNIDATA/".   Under that, Scripts.txt tells the different scripts one can write in.  An excellent reference for all of this (which seems to be 'the Bible' for fonts and encodings is the book, "Fonts & Encodings by Yannis Haralambous".  It has all of the URLS in there as well as usage of the tools to deal with the fonts. 

One tool (2 tools together, actually), I might recommend for exploring the different font mappings (it can allow you to create a "Composite" mapping using all the fonts on your system, of as many of the Unicode characters as possible are tools "Babelmap and Babelpad".  Best of all, they are Free!  Bablemap can be used to create an XML file that maps fonts to each of the scripts (well, all of the scripts you have fonts for, anyway).  It's similar to the Windows "Character Map" program, but on steroids!   It's only on Windows (Mac and X users have other tools mentioned in the book), and supports up to Unicode V 5.1.0 [http://www.unicode.org/versions/Unicode5.1.0/].  It's website is "http//:www.BabelStone.co.uk/Software/BabelMap.html".

Using a config tool like that, one could define a complete set of fonts to use within another program (like Vim!)  to provide font mapping.

I know Enhancement 2 might be a ways away, but would #1 be doable in any near time frame?


Thanks,
Linda




--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: RFE/RFC?:desired enhancement or 'already in there'? backups fonts for unmapped chars, families and Unicode blocks

Charlie Kester

On Thu 10 Sep 2009 at 19:58:03 PDT Linda W wrote:
>
>  (If you can't read this in HTML, you are deprived, and maybe, in the
>  internet "3rd world", my condolences, as documents structure can't be
>  properly represented in plain text, (unless your eyes have built-in
>  XML/HTML or LaTeX code interpretation).

I'm sorry, but my eyes got cross-eyed after reading your gratuitous
insult and I wasn't able to pay any more attention to your RFC.

I disagree with your claim that document structure can't be properly
represented in plain text, because I don't think document structure has
anything to do with fonts, point sizes, italics, underlining, etc.
Those are all matters of *appearance* not structure.


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: RFE/RFC?:desired enhancement or 'already in there'? backups fonts for unmapped chars, families and Unicode blocks

Benjamin Fritz
In reply to this post by L. A. Walsh



On Sep 10, 9:58 pm, Linda W <[hidden email]> wrote:
> The only ones that look halfway readable are the Lucida
> family...followed by the Monospace 821.  .  New courier is just too
> thin.  Consolas isn't much better (a free font
> download from MS, no less!)

I've gotten a lot of good use from DejaVu Sans Mono which you mention
briefly, without giving a reason as to why you don't like it. I can
understand the frustration, though. The first time I saw DejaVu I
thought, "ick" but it has slowly grown on me. Consolas I like most of
the time, but a few glyphs (like M and N oddly enough) look disgusting
enough I only use it as a fallback if DejaVu is not installed.

>
>
>           Desired Enhancement 1:   Font Lists, acting as fall-through
>           backups for missing chars
>
> I'd first like something like the 'guifontset' option work to
> automatically use successive entries on the font list as 'fallback'
> entries if the character being displayed isn't in the currently selected
> font.
>
> [snip]
>
>           Desired Enhancement 2:   Support of Font Families
>
> If this were supported, one could actually specify what font to use for
> what named Unicode block.
> The names of the blocks are published and can be tested.

The problem I see with both of these mappings is that Vim creates a
"grid" of sorts based on a certain number of characters, upon which it
draws everything. This grid is set up under the assumption that every
character is the same size. This is a valid assumption for characters
within a single monospaced font, but as soon as you start mixing fonts
it is no longer valid.

For similar reasons, guifont is a global option rather than tab-local,
and non-monospaced fonts look terrible when you force Vim to use them.
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: RFE/RFC?:desired enhancement or 'already in there'? backups fonts for unmapped chars, families and Unicode blocks

Raúl Núñez de Arenas Coronado-2
In reply to this post by L. A. Walsh

Linda W  <[hidden email]> skribis:
> (If you can't read this in HTML, you are deprived, and maybe, in the
> internet "3rd world", my condolences, as documents structure can't be
> properly represented in plain text,

Oh, I can read this in HTML, but thanks for the insult anyway and
welcome to my killfile.

--
Raúl "DervishD" Núñez de Arenas Coronado
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: RFE/RFC?:desired enhancement or 'already in there'? backups fonts for unmapped chars, families and Unicode blocks

J.A.J. Pater
In reply to this post by L. A. Walsh

 > (If you can't read this in HTML, you are deprived, and maybe, in the
internet "3rd world", my condolences, as documents structure can't be
properly represented in plain text, (unless your eyes have built-in
XML/HTML or LaTeX code interpretation).

I agree with Charlie and Raúl.
HTML is plain text also but with a lot of markup (meta-info) between the
(real) info.

As noted on this list before: some blind computer users prefer plain text
because some text to speech programs mangle HTML input.
Dear Linda, isn't it a little rude to banish them to "the internet 3rd
world"?

This is only one reason to adhere to list policy, so please don't use
HTML.


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: RFE/RFC?:desired enhancement or 'already in there'? backups fonts for unmapped chars, families and Unicode blocks

bill lam
In reply to this post by L. A. Walsh
On Thu, 10 Sep 2009, Linda W wrote:
> (If you can't read this *_in HTML_*, you are deprived, and maybe, in the
> internet "3rd world", my condolences, as documents structure can't be
> properly represented in plain text, (unless your eyes have built-in
> XML/HTML or LaTeX code interpretation).


I think that your claim is ungrounded, the following is the same
document in plain text.


  • Contents

      □ Current Problem

      □ Desired Enhancement 1:   Font Lists, acting as fall-through backups for missing chars

      □ Desired Enhancement 2:   Support of Font Families



Current problem:

(If you can't read this in HTML, you are deprived, and maybe, in the internet "3rd world", my condolences, as
documents structure can't be properly represented in plain text, (unless your eyes have built-in XML/HTML or
LaTeX code interpretation).

I've been trying to use better fonts and Unicode usage in my work (email, web pages, etc).  Of source, using Vim
for just about everything (Does anyone know of a Thunderbird extension to automatically allow or call Vim to
edit dir Thunderbird composition --- especially when one switches into 'Source(HTML)' mode...that editor *sucks*
big-time..., but I digress.

I really am getting discouraged with the fonts available to me in monospaced fonts.

The only ones that look halfway readable are the Lucida family...followed by the Monospace 821.  .  New courier
is just too thin.  Consolas isn't much better (a free font
download from MS, no less!)

    My font (in Truetype or OpenType) list has: several monospace fonts that specialize in the CJK  block, but
non of those have great latin rendering and little coverage for Unicode blocks outside of the CJK blocks  those
include:  (all the 'che variations seem to be the monospace ones) Batang, Doton Gulim Gunshuh, Jurchen Krystoid,
MingLiU, MS Gothic, and MS Mincho.

The few that specialize in the Hebrew block, don't help me much: Fixed Miriam Transparent, Rod (& Rod
Transparent), neither the one in Arabic (Simplified Arabic Fixed).  Non Unicode, symbol-only or raster fonts I
won't mention in this listing.

Among the Unicode fonts, ones that have western font and western usage (symbols, etc) coverage , I list the
number of Unicode blocks they cover as well as total characters in the font.  There are only 9 choices on my
system, (though I describe one's coverage in detail with the lament that for some unknown reason, it isn't
offered on the list, though it's 2nd plane 'cousin' is):


┌─────────────────────┬──────┬───────────┬──────────────────────────────┐
│Name                 │Blocks│Total-Chars│  Comments                    │
├─────────────────────┼──────┼───────────┼──────────────────────────────┤
│Andale Mono          │22,   │654        │                              │
├─────────────────────┼──────┼───────────┼──────────────────────────────┤
│Bitstream Vera Sans  │12    │256        │                              │
│Mono                 │      │           │                              │
├─────────────────────┼──────┼───────────┼──────────────────────────────┤
│Code2002             │11    │20,409     │  [sic/broken] this entry is  │
│                     │(CJK) │           │broken                        │
└─────────────────────┴──────┴───────────┴──────────────────────────────┘


     

    Note on Code2002:  It is the 3rd font in a 3 font series (Code2000, Code2001, and Code2002, all available
    for very low (as low as $0) price (shareware(non-crippled)) or freeware from http://www.code2000.net/). All
    are monospaced fonts. Code2000 was for our first 64K (MS's initial UCS-2 set for NT4) code plane.  When
    discovering 64K was no where near enough, more planes were added.  Code2001 is for Unicode Plane 1 and
    Code2002 is for plane 2.  Code 2000 -- the one that contains the latin characters doesn't show up as a
    choice, though it should -- they are all monospaced fonts;  Code2002 is useless for Latin fonts (has 95/128
    of Basic, 1/128 of Ext-A, 1/208 of Ext-B 96/129 of Supplement-1, 1/80 of Spacing modifiers), vs "Code2000"
    which is designed to cover Plane 1 (first 64K),  which has 118 blocks and 54,068 chars).  It's not the most
    excellent looking (at 1024^2 points per char) it was designed with less resolution than MS's TTF fonts, like
    Lucida Console (@4096^2 ppc), BUT on the list of unicode fonts it's pretty darn good, and probably 2nd best
    after the top MS fonts (which have no where near the coverage -- it could be there's a tradeoff -- 4x4 or 16
    times the resolution/char OR 54,068/663 = 81 times the coverage.


    Of Latin usable chars, it has

          ☆ all alphabetic presentation forms (58/58),
          ☆ all arrows(112/112),
          ☆ 95/128 of Basic Latin
          ☆ all the Box drawing chars (128/128),
          ☆ all Braille Patterns (256/256)
          ☆ Combining diacriticals [like accents over chars) (112/112)
          ☆ Combining for symbols (28/33) & supplement (13/41) & half marks(4/7)
          ☆ control pics (symbols for the control characters below like "LF", TAB, CR"; 39/39);
          ☆ 22/22 Currency symbols 174/174 Dingbats (all the special symbols designed by the designer "Zapf"
            last century)
          ☆ 160/160 Enclosed alpha numerics
          ☆ 106/107 General Puncuntuation
          ☆ Greek symbols (2 blocks: 134/134+233/233)
          ☆ halfwidth and full width forms (including !!colon!! that you can put in Windows (and linux)
            filenames: "file:foobar" (the character after 'file' and before 'foobar' is a single character
            composed of a colon and an embeded space.  It is legal in WinXP and above and linux  (and likely
            MAC) if you are using UTF-8.  It displays as a colon followed by a space!  So in a linux shell, you
            don't need to quote it -- it's not a space breaking character!
          ☆ Then 6 Latin extended blocks "extended additional(256/25), A(128/128) B(208/208) C(29/29), D(114/
            114) & Latin-1 Supple(96/128)
          ☆ Letter like symbols (like the C for Centigrade, or 'c/o' as a single char(80/80)
          ☆ Mathematical Operators (256/256), Math symbols A (44/44), B(128/128)
          ☆ Misc Symbols(183/191), Misc Sym+Arrows(82/82)
          ☆ Misc Technical (228/232)
          ☆ Number Forms (Roman numberals, fractions, et al) (54/54)
          ☆ OCR (11/11)
          ☆ Phonetic Extensions (128/128) & Supplements (64/64) (for pronuncation)
          ☆ Spacing modifiers (including small spaces, the ever used &nbsp, (80/80)
          ☆ Superscripts/subscripts (29/34)
          ☆ Supplemental: Arrows A(16/16), Arrows B(128/128), Math(256/256) and Punctuation(49/49)

    AND a bunch of foreign languages symbols ... but due to some bug, somewhere, and I don't think it is in Vim,
    since it is also in 'SecureCRT' (http://www.vandyke.com/products/securecrt/index.html), my Win->lin TTY
    program (that also supports UTF-8) has same font list as Vim and includes Code2002, but not Code 2000. Grrr!
    It seems like it's some bit not set right somewhere, so Windows isn't displaying the correct font list...or,
    it's JAMSB (Just another MicroSoft Bug) :-).


Continuing, a few last fonts...other fonts:

┌─────────────────────┬────────────┬────────────────────────────────────┐
│Name                 │blocks,chars│ Comments                           │
├─────────────────────┼────────────┼────────────────────────────────────┤
│Courier New          │(28, 1230)  │but this font isn't easy on the eyes│
├─────────────────────┼────────────┼────────────────────────────────────┤
│DejaVu Sans Mono     │(39, 2900)  │                                    │
├─────────────────────┼────────────┼────────────────────────────────────┤
│Everson Mono         │(67, 6391)  │2nd best coverage, poor readability)│
├─────────────────────┼────────────┼────────────────────────────────────┤
│Lucida Console       │(22, 663)   │Best readable (IMO)                 │
├─────────────────────┼────────────┼────────────────────────────────────┤
│Lucida SansTypewriter│(12, 240)   │fairly good read, taller/thinner    │
└─────────────────────┴────────────┴────────────────────────────────────┘


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Desired Enhancement 1:   Font Lists, acting as fall-through backups for missing chars


I'd first like something like the 'guifontset' option work to automatically use successive entries on the font
list as 'fallback' entries if the character being displayed isn't in the currently selected font.  That way, I
can have my primary, and a backup, and, possibly a catchall, though I could see this being also used to support
multiple families -- like if I write in Cherokee, I could have a Cherokee font in my list, and when I typed in
that font, Gvim  would automatically fall through the fonts that don't have those chars mapped,
and would display chars from a font with those chars mapped.

I would expect that the fonts would be examined once, on startup, with maybe a 'cache-file' being created, of
the mappings (if the examination process takes any appreciable length of time).  Once examined, the mappings
could be used automatically at runtime.


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Desired Enhancement 2:   Support of Font Families

If this were supported, one could actually specify what font to use for what named Unicode block. 
The names of the blocks are published and can be tested.  Perl has had this support for a few years, for example
(man perlunicode).  All of the information on the ranges and glyph names can be found on "http://www.unicode.org
" . 

The data files are in the directory "http://www.unicode.org/Public/UNIDATA/".   Under that, Scripts.txt tells
the different scripts one can write in.  An excellent reference for all of this (which seems to be 'the Bible'
for fonts and encodings is the book, "Fonts & Encodings by Yannis Haralambous".  It has all of the URLS in there
as well as usage of the tools to deal with the fonts. 

One tool (2 tools together, actually), I might recommend for exploring the different font mappings (it can allow
you to create a "Composite" mapping using all the fonts on your system, of as many of the Unicode characters as
possible are tools "Babelmap and Babelpad".  Best of all, they are Free!  Bablemap can be used to create an XML
file that maps fonts to each of the scripts (well, all of the scripts you have fonts for, anyway).  It's similar
to the Windows "Character Map" program, but on steroids!   It's only on Windows (Mac and X users have other
tools mentioned in the book), and supports up to Unicode V 5.1.0 [http://www.unicode.org/versions/Unicode5.1.0/
].  It's website is "http//:www.BabelStone.co.uk/Software/BabelMap.html".

Using a config tool like that, one could define a complete set of fonts to use within another program (like
Vim!)  to provide font mapping.

I know Enhancement 2 might be a ways away, but would #1 be doable in any near time frame?


Thanks,
Linda







--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: RFE/RFC?:desired enhancement or 'already in there'? backups fonts for unmapped chars, families and Unicode blocks

Matt Wozniski-2
In reply to this post by Raúl Núñez de Arenas Coronado-2

2009/9/11 Raúl Núñez de Arenas Coronado <[hidden email]>:
>
> Linda W  <[hidden email]> skribis:
>> (If you can't read this in HTML, you are deprived, and maybe, in the
>> internet "3rd world", my condolences, as documents structure can't be
>> properly represented in plain text,
>
> Oh, I can read this in HTML, but thanks for the insult anyway and
> welcome to my killfile.

A "me too" for not even bothering to read past the first paragraph.

~Matt

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: RFE/RFC?:desired enhancement or 'already in there'? backups fonts for unmapped chars, families and Unicode blocks

Glen Pfeiffer
In reply to this post by L. A. Walsh

On Thu Sep 10, 2009 at 07:58:03PM -0700, Linda W wrote:
> (If you can't read this *_in HTML_*, you are deprived, and
> maybe, in the internet "3rd world", my condolences, as
> documents structure can't be properly represented in plain
> text, (unless your eyes have built-in XML/HTML or LaTeX code
> interpretation).

Not only did you ignore the list policy, but you insulted those
who created it, follow it, and like it. That doesn't seem like a
very intelligent way to go about it.

--
Glen


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Using beautiful fonts vs. monospace plaintext.

L. A. Walsh



It didn't occur to me that such a policy would follow the vim
list when it became hosted on web-enabled group host'er like
google-groups.

I'm not sure how the text you include below is insulting.  It
was meant in truth.  If you are unable to read my HTML posting,
rendered in HTML, I felt you would be deprived, as it was well formatted
and I spent a large block of time over 3 days composing it.

I DID, despite the comments of those ignorant of email structure,
post it in plaintext as well as in HTML.

I  *felt*  that those who read the plain text version were deprived.
(Using the hyperbole of them being in a electronic 3rd world
that only has tty terminals to display text, instead of monitors
that can display proportional fonts).

How is it that, "my" feeling, that someone who is reading "my" email,
only in plaintext, when I put such effort into the HTML formatting, is
insulting?

The plaintext version comes *first* in the email.  Those who read the
email in HTML, CHOSE, to do so.    How is that *my* fault?

In T-Bird, and *even* MS-Outlook, you can configure email reading
to only look at the plain text portion of messages.  If you choose to
let emails be displayed, then it is your *choice* to do so.  This is what
the RFC standards are for -- they have alternate parts for alternate display
devices.


How was it decided that the list policy would ignore or not allow for
RFC standard email?

Perhaps that decision needs to be re-examined?

And -no-, I'm not saying you open the door to flash-enabled players or
embedded music, or animations.  Well, I could see embedding a video
of how a user wants a Vim feature to work or even a 'howto use VIM',
video, and how simple the GUI is to use...or something similar, but it
would be an exception to the rule -- I always have "no-script" and
"ad-block" running by default -- even hacked them to install in T-bird
after I installed a -web-browser extension in T-bird.  This stuff isn't
rocket science -- Tbird blocks remote images unless you allow them
and blocks scripts as well.  It's been in 'one form or another' since
the mid
80's.

Maybe I'll get time to get to some other responses -- but this email isn't
the venue... (it would too easily be missed).

-l





Glen Pfeiffer wrote:

> On Thu Sep 10, 2009 at 07:58:03PM -0700, Linda W wrote:
>  
>> (If you can't read this *_in HTML_*, you are deprived, and
>> maybe, in the internet "3rd world", my condolences, as
>> documents structure can't be properly represented in plain
>> text, (unless your eyes have built-in XML/HTML or LaTeX code
>> interpretation).
>>    
>
> Not only did you ignore the list policy, but you insulted those
> who created it, follow it, and like it. That doesn't seem like a
> very intelligent way to go about it.
>
>  



--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Using beautiful fonts vs. monospace plaintext.

fuzzymo

Vim is a text editor. vim_use is a text list.

It's not a stretch, even if hosted on a webserver, to assume that the
list would retain the same tenor as the original.

On Mon, Sep 14, 2009 at 10:32 PM, Linda W <[hidden email]> wrote:

> It didn't occur to me that such a policy would follow the vim
> list when it became hosted on web-enabled group host'er like
> google-groups.

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Using beautiful fonts vs. monospace plaintext.

L. A. Walsh

And I use vim to edit/create my CSS and HTML-email...

So your point is...?



Fuzzy Logic wrote:

> Vim is a text editor. vim_use is a text list.
>
> It's not a stretch, even if hosted on a webserver, to assume that the
> list would retain the same tenor as the original.
>
> On Mon, Sep 14, 2009 at 10:32 PM, Linda W <[hidden email]> wrote:
>
>  
>> It didn't occur to me that such a policy would follow the vim
>> list when it became hosted on web-enabled group host'er like
>> google-groups.
>>    
>
> >
>  


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Using beautiful fonts vs. monospace plaintext.

fuzzymo

Not surprising, I hope, but my point was exactly what I said:
>> It's not a stretch, even if hosted on a webserver, to assume that the
>> list would retain the same tenor as the original.

Frankly, I use vim to edit binary files, but I would suggest sending
binary data to a mailing list.

On Mon, Sep 14, 2009 at 10:54 PM, Linda W <[hidden email]> wrote:

> And I use vim to edit/create my CSS and HTML-email...
>
> So your point is...?
>
> Fuzzy Logic wrote:
>> Vim is a text editor. vim_use is a text list.
>>
>> It's not a stretch, even if hosted on a webserver, to assume that the
>> list would retain the same tenor as the original.

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Using beautiful fonts vs. monospace plaintext.

panshizhu
In reply to this post by L. A. Walsh

Linda W 写道:

> It didn't occur to me that such a policy would follow the vim
> list when it became hosted on web-enabled group host'er like
> google-groups.
>
> I'm not sure how the text you include below is insulting.  It
> was meant in truth.  If you are unable to read my HTML posting,
> rendered in HTML, I felt you would be deprived, as it was well formatted
> and I spent a large block of time over 3 days composing it.
>
> I DID, despite the comments of those ignorant of email structure,
> post it in plaintext as well as in HTML.
>

Please google for RFC official website, download them, read them, you'll
know all RFCs are well structured, and all RFCs *are* plain text.
stating that text structures cannot be properly represented in plain
text is simply an ignorance.

HTML post is generally rude in hacker culture / internet culture,
because you *force* users to use *your* font name and your font size and
your foreground/background to view the text. while in most case this
kind of *force* is unnecessary.

It would be much helpful if you post your RFC in real RFC format, yes,
they are well structured plain-text.


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Using beautiful fonts vs. monospace plaintext.

bill lam
In reply to this post by L. A. Walsh

On Mon, 14 Sep 2009, Linda W wrote:
> I DID, despite the comments of those ignorant of email structure,
> post it in plaintext as well as in HTML.

No, you didn't.  You did not take time to format a plain text message.
It was the Thunderbird (mua) that automatically rendered the html into
plain text and it rendered it badly, eg. it could not render tables.
This is not a complaint to thunderbird because that is not its
primary duty.  It is even acceptable if mua just make up a message
saying "There is a html attached." as the plain text portion.

--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

RE: Using beautiful fonts vs. monospace plaintext.

JohnBeckett

Folks, please do not debate this topic! Anyone is welcome to
post any kind of message they like SOMEWHERE ELSE.

This mailing list has an agreed guideline:
http://groups.google.com/group/vim_use/web/vim-information

On this list we use PLAIN TEXT and we bottom post.

Anyone is welcome to debate the merits of these decisions
SOMEWHERE ELSE.

John


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Using beautiful fonts vs. monospace plaintext.

L. A. Walsh
In reply to this post by panshizhu



The RFC started in plain text because that was all that was available.

But look at the *internet* documents from the Web consortium on CSS, or
documents on fonts or on color profiles -- none are in plain text.

The spec for adobe PDF isn't in plain text.

plain text main be fine for nuts and bolts --- low level tech info, but
if you are discussing anything above the level of protocols, you tend to
write in such.  I was discussing the use of fonts and multi font
support.  It's hard to make examples of multi font support in plain text.

Furthermore, plain text documents are not tagged and not easily indexed
for structure.  Some, can be, but when documents are tagged with headers
and hyperlinks they provide meta information that, if provided inline,
interfere with reading.  I don't force you to read my fonts.  Again,
your reader allows you to over ride my fonts -- and furthermore, its
*my* message.  It's like my __name__, why can't I spell and style it as
I wish?  It was American imperialism that forced many foreigners to
change their names when they moved to America in the past.  But the US
is supposed to be the land of freedom -- yet strong coercion or verbal
violence is used against anyone who steps out of line. This is freedom?

I was around on the internet before it was the internet, and on
networked computers across the states back in the 70's and 80's, so I'd
wager I have a broader perspective on this than most of the people on
this list.  My degree is in computer science, so again, I suspect I have
a stronger background than a large number of folks -- I'm not speaking
out of ignorance when I say that your intolerance is that which is
holding the world back and keeping the world stagnant and from
progressing.

You are becoming your parents parents -- conservative and narrow minded
and I'd wager that the majority of the complainers are in their 30's-mid
40's, at most.

You are condemning the world to mediocrity and never progressing.

Change and grow!  Stop being miniature dictators who demand compliance
of all around them.
I've seen the RFC's -- they are designed for the lowest common
denominator.  I didn't force you to use my fonts -- you'd have to have
them loaded in the first place on your machine.  Again -- your choice to
even have them on your machine.

AND AGAIN, I point out the inescapable fact that I posted the plaintext
version of my file for those who really do have email readers that only
read plain text.  If you read it in HTML, it was your choice -- not
something thrust upon you.

I gave you the message *both* ways, yet most of you only saw the HTML.
Why is that?  Because you *prefer* HTML! -- You your email reader set
to display HTML OVER plaintext when HTML is available.

How is this an example of me forcing you?

-l


pansz wrote:

> Linda W 写道:
>  
>> It didn't occur to me that such a policy would follow the vim
>> list when it became hosted on web-enabled group host'er like
>> google-groups.
>>
>> I'm not sure how the text you include below is insulting.  It
>> was meant in truth.  If you are unable to read my HTML posting,
>> rendered in HTML, I felt you would be deprived, as it was well formatted
>> and I spent a large block of time over 3 days composing it.
>>
>> I DID, despite the comments of those ignorant of email structure,
>> post it in plaintext as well as in HTML.
>>
>>    
>
> Please google for RFC official website, download them, read them, you'll
> know all RFCs are well structured, and all RFCs *are* plain text.
> stating that text structures cannot be properly represented in plain
> text is simply an ignorance.
>
> HTML post is generally rude in hacker culture / internet culture,
> because you *force* users to use *your* font name and your font size and
> your foreground/background to view the text. while in most case this
> kind of *force* is unnecessary.
>
> It would be much helpful if you post your RFC in real RFC format, yes,
> they are well structured plain-text.
>
>
> >
>  


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Using beautiful fonts vs. monospace plaintext.

L. A. Walsh
In reply to this post by bill lam



I expected my email program to include a plaintext copy.  I specifically
chose NOT to send it, only in HTML.  IT was a conscious choice.
I'm very bad at formatting in plain text.  I find it a nearly impossible
task.

Even in college, when others were still using typewriters and dot matrix
printers, I was using troff to generate my papers for classes -- I
couldn't make it work in plain text.  You may not get this, but I really
have major problems formatting things in plain text.   Hyperlinks?
forget it.  Alternate fonts or tables?  nearly impossible.  Sorry, but
you are wrong.  I did choose and DID include a plain text copy.  But the
structure it came up is about as well as I've done in the past.

But that's also the beauty of HTML with CSS style sheets, if you don't
like my formatting, you can use your own formatting and make it look
however you want.  You can't do that with plain text without editing the
content.

-l

bill lam wrote:

> On Mon, 14 Sep 2009, Linda W wrote:
>  
>> I DID, despite the comments of those ignorant of email structure,
>> post it in plaintext as well as in HTML.
>>    
>
> No, you didn't.  You did not take time to format a plain text message.
> It was the Thunderbird (mua) that automatically rendered the html into
> plain text and it rendered it badly, eg. it could not render tables.
> This is not a complaint to thunderbird because that is not its
> primary duty.  It is even acceptable if mua just make up a message
> saying "There is a html attached." as the plain text portion.
>
>  


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Using beautiful fonts vs. monospace plaintext.

L. A. Walsh
In reply to this post by JohnBeckett



And this decision was made by a gender balanced committee, discussed
when?  Is this about Vim and how to make it better and use it for many
purposes or about forcing people into compliance ?

Gawd, I hate emacs -- because they are so 'you must do it our arcane way
and there is no other.  But I see vim is becoming the same way...very sad.

Are you saying there is a 'vim-use-use' list? for meta discussions n the
use of vim-use?  ;^)?

-l


John Beckett wrote:

> Folks, please do not debate this topic! Anyone is welcome to
> post any kind of message they like SOMEWHERE ELSE.
>
> This mailing list has an agreed guideline:
> http://groups.google.com/group/vim_use/web/vim-information
>
> On this list we use PLAIN TEXT and we bottom post.
>
> Anyone is welcome to debate the merits of these decisions
> SOMEWHERE ELSE.
>
> John
>
>
> >
>  


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Using beautiful fonts vs. monospace plaintext.

François Ingelrest
In reply to this post by L. A. Walsh

On Tue, Sep 15, 2009 at 10:28, Linda W wrote:
> The RFC started in plain text because that was all that was available.
>
> ...

I honestly don't see where all this discussion is going.

Who cares about which document is written in which format? This is a
mailing list, a place where a community lives. To live together, we
need rules. One of them is "use plain text", because not everyone
can/wants to see something else. Period.

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Using beautiful fonts vs. monospace plaintext.

Yongwei Wu

2009/9/15 François Ingelrest <[hidden email]>:

>
> On Tue, Sep 15, 2009 at 10:28, Linda W wrote:
>> The RFC started in plain text because that was all that was available.
>>
>> ...
>
> I honestly don't see where all this discussion is going.
>
> Who cares about which document is written in which format? This is a
> mailing list, a place where a community lives. To live together, we
> need rules. One of them is "use plain text", because not everyone
> can/wants to see something else. Period.

Ditto.

Although I am not one of them, I guess there are still some people
using a text-only MUA. HTML messages are irritating for them.

(I know and understand the merits of well-formatted HTML messages,
which can convey information absent in the text, like the language.
However, text messages can achieve most purposes, and serve well as a
common denominator.)

Linda, I sympathize with your opinions, but I think it is better not
to post repeatedly on a topic that can easily rouse annoyances and
flames.  And you were top-posting too.

Best regards,

Yongwei

--
Wu Yongwei
URL: http://wyw.dcweb.cn/

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

123