The Unicode Consortium Discussion Forum

The Unicode Consortium Discussion Forum

 Forum Home  Unicode Home Page Code Charts Technical Reports FAQ Pages 
 
It is currently Tue Nov 25, 2014 5:02 pm

All times are UTC - 6 hours [ DST ]




Post new topic Reply to topic  [ 5 posts ] 
Author Message
 Post subject: space or blank gylph for Block Elements
PostPosted: Tue Jan 21, 2014 3:10 am 
Offline

Joined: Sun Jan 19, 2014 8:03 am
Posts: 2
In the "Block Elements" Unicode block there are a bunch of graphical glyphs which allow compatibility with, for example, ZX Spectrum semigraphics and DOS (code page 437):

▖▗▘▙▚▛▜▝▞▟░▒▓

These (presumably) have a fixed width, so they line up for multi-line images.

The problem is that while there are a large number of "space" characters defined in Unicode, none seem to be defined as being the width of a "block element". This makes the use of images made in block characters almost impossible when used within proportional typeface text.

A space character which matches the width of block elements would allow intermixing of block elements with normal proportionally spaced text. E.g. both spaces should be the same width in the text: "The old machined show the semigraphical characters: ▞▞▖▝▞ ▞▞▖"

So my questions:

1. Are the "Block Elements" defined to match the width of any existing Unicode space element (e.g. En Space, Em Space, Three-Per-Em Space, Figure Space, etc.)

2. If not, would it be reasonable to propose a "non-breaking block element blank" for use with the block elements?

Unfortunately the Block Elements block is full, and it looks like 7.0 will be using up the final code points in the General Punctuation block, so I'm not sure where a "Block Element blank" would best fit, if it were to be proposed.

I'm focusing on Block Elements in this message, but the same questions apply for the "Box Drawing" block or the monospaced Latin characters in the "Mathematical Alphanumeric Symbols" block, as these would also benefit from a blank space character which matched their width.

Apologies if these issues have been discussed ad nauseam before but I couldn't find any info. Any response is appreciated.


Top
 Profile  
 
 Post subject: Re: space or blank gylph for Block Elements
PostPosted: Tue Jan 21, 2014 4:46 am 
Offline
Unicode Guru

Joined: Tue Dec 01, 2009 2:49 pm
Posts: 189
@pengo: the block elements were intended to be used with the standard space character (U+0020).

The systems that used these block elements had fixed display cells, and a space character had the width of a display cell.

What you are trying to do is to use these characters when they are supported in a single font with all the rest of Unicode. In that case, the width of U+0020 is no longer a perfect fit for the block elements - nor is it necessarily a perfect fit for all other scripts or collections of characters.

It seems natural then, to want to control the width of the space actually used between such characters.

You have to ask yourself, though, whether controlling that width is still considered *plain text*, because the width could, in principle, be determined by referencing the surrounding characters, instead of having to be given as part of the input (i.e. by using a special character code).

Using a special character code would invalidate any mapping to legacy data formats, but this concern may not be one that's of much practical use, unless you happen to have an emulator. So, I'll put that aside.

Then there's the question of what the use case is for these characters outside the legacy environment. You must have played with these for some purpose, but it seems that you are not using them as part of a notational system or part of an established user community with its own conventions. That means, so far, we have to assume these aren't really used, except by a few people to toy around. That's more of concern, because any new character would then not necessarily have much use either.

For toying around, it would seem that the best way to get your results would be to use a font that contains *only* the block elements (and the space) and to make sure that for that font, the width of the space matched the other elements. Then you can use rich text (i.e. definite font selection) to get the effect you want.

If, for any reason, this or one of the other collections of such symbols ever gets used in a scenario where (for a sizable community) such use of rich text is unworkable and spaces between these do have to be correct when using a global (all-Unicode) font, then there would be a basis for having a discussion of what the potential solutions would be.

I'm not a font designer enough to know offhand whether OpenType allows you to adjust the width given to U+0020 based on surrounding characters, if it does, then getting that supported widely would be the next best solution, I wager.

Adding new space characters would be the last resort, because it would invalidate so much software: you may well want software to continue to identify U+0020 for purposes like word breaking (and use U+00A0 when that is undesirable), for example.


Top
 Profile  
 
 Post subject: Re: space or blank gylph for Block Elements
PostPosted: Thu Jan 23, 2014 7:07 pm 
Offline

Joined: Sun Jan 19, 2014 8:03 am
Posts: 2
Thanks for the prompt response.

I'm going to largely ignore the part about gathering evidence for its use for now:

Quote:
Then there's the question of what the use case is for these characters outside the legacy environment. You must have played with these for some purpose, but it seems that you are not using them as part of a notational system or part of an established user community with its own conventions. That means, so far, we have to assume these aren't really used, except by a few people to toy around.


Gathering evidence for use is difficult. For one, search engines aren't geared towards searching for sets of Unicode characters (or even single Unicode characters).

The ZX Spectrum does appear to be having a revival at the moment, but I have not attempted, e.g. to trawl message boards for anyone discussing block elements in Unicode.

However, the larger problem is that if the code block is—as I am putting the case forward for here—incomplete, then this will have severely curtailed its use, and have prevented the establishment of communities using the characters.

For example in plain text messaging (e.g. SMS, Twitter, Facebook, and many email clients), the lack of a "blank" makes the use of block elements awkward at best, limiting any community which might form organically.

asmus wrote:
The systems that used these block elements had fixed display cells, and a space character had the width of a display cell.


Yes, but now it's intermixed with other text, as it's in Unicode.

Quote:
...the width could, in principle, be determined by referencing the surrounding characters, instead of having to be given as part of the input (i.e. by using a special character code).


No, that's impossible, as spaces at the start, end, or middle may refer to a normal word space, or may refer to a block element blank. Trying to tell from context would be guesswork at best.

For example, to go back to the simple example of ▝▞ ▞▞. It's ambiguous, and may be interpreted in different ways:

1. if interpreted as a normal space, it may refer to two chunks of block characters: "▝▞" and "▞▞", with a space separator.

2. if the space is interpreted as a block-element blank, it would be seen as a single graphical unit, which can only be rendered correctly using markup:
Code:
▝▞ ▞▞
.

I use the term "blank" rather than "space", as this usage is not semantically a space and should not be a breaking element. The Braille block similarly has a Blank (i.e. "no dots raised"), which may be rendered with no glyph, but is not semantically a space, even though it may come from systems which originally encoded it as one. The Block Elements block is incomplete without a blank.

Quote:
Adding new space characters would be the last resort, because it would invalidate so much software: you may well want software to continue to identify U+0020 for purposes like word breaking (and use U+00A0 when that is undesirable), for example.


It wouldn't invalidate any software any more than adding any other Unicode element, other than highly specialized software which would otherwise have no way of differentiating the intention of the author: whether they meant for a space to be a space or for it to be a blank in a semigraphical construct.


Top
 Profile  
 
 Post subject: Re: space or blank gylph for Block Elements
PostPosted: Tue Feb 25, 2014 4:31 am 
Offline

Joined: Mon Feb 01, 2010 6:18 pm
Posts: 79
Asmus, correct me if I'm wrong here, but shouldn't the em space be the same width as a block element, with the en space a half block?


Top
 Profile  
 
 Post subject: Re: space or blank gylph for Block Elements
PostPosted: Tue Feb 25, 2014 11:49 am 
Offline
Unicode Guru

Joined: Tue Dec 01, 2009 2:49 pm
Posts: 189
vanisaac wrote:
... shouldn't the em space be the same width as a block element, with the en space a half block?


in a font that contains only block elements and spaces that is in deed what I would expect.

However, there's nothing that says that a block element, in a mixed font, would absolutely correspond to an em width.

Your point, though, is a good one.

For ordinary, in-text use, something like an em-space might do the trick, even if it is only approximately the correct width. Only when you try to use block elements the way they were designed originally (to make patterns on terminals) would you need more. In that case, the simplest answer is to use a font that makes the proper guarantees.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 

All times are UTC - 6 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


Quick-mod tools:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Template made by DEVPPL.com