On Sat, 16 Nov 2013 21:59:04 +0000
jonathon <firstname.lastname@example.org> wrote:
On 11/16/2013 08:17 PM, Paul wrote:
Taking, thorn, for example, with the current setup, one knows to
look in the Runic range.
You might, but that doesn't mean everybody does.
Only if one has paid absolutely no attention to how glyphs in the font
are organized. Even a thirty second scan shows that it is ordered by
That assumes, among other things, that the user knows what thorn is. As
an example, let's say the user wants to write a small section about
mathematical sets, and needs the intersection symbol. I just tried to
look that up in the special characters dialog, and had absolutely no
idea where it was. And the list was simply too long to search through
by brute force. Luckily, one of the subsets is helpfully named
"Mathematical Operators". Makes it very easy to find. But why are there
no "Engineering Operators" or "Electrical Operators"? Now what do I do
if I need one of those?
Yes, I realise why there are no such categories defined within unicode,
that's not my point. My point is if that's what I'm looking for, it
would be handy to have such a subset.
when the sub-range is at the whim of a programmer, it could be
Sure, but the assumption is that it is easier to find a glyph by
usage than by name
The issue you fail to recognize is that the same glyph can be used in
any number of different fields, to represent very different concepts
You are mistaken. I don't fail to recognise that. I am fully aware of
that. And there is nothing stopping the same unicode character being
included in multiple filters.
Perhaps you don't fully understand how the proposed system works.
The claim is that the current filters are inadequate. Thus, the
need to dummy it down, so that it is less efficient, more time
consuming, and awkward to use.
Why on earth would I want to make it *more* complex if it is too
difficult as it is? I can see you clearly don't understand the
Take a look at the problems created by the various types of indexing
methods used for Chinese dictionaries, and why each of those indexing
solutions is touted as being the best, and thus only system that
should be used.
Not knowing anything about this, I won't comment. But you tell me, why
exactly is my system "more complex"?
But because less glyphs are displayed, Joe Sixpack thinks it is
easier to use.
Exactly. So useful for Joe Sixpack, if not for you.
Less glyphs displayed means more pages have to be viewed to find the
appropriate glyph. Which means that in the long run, it will be even
more awkward for Joe Sixpack.
Only if it's not in the filter he thinks it is in. Chances are he has
at least some idea of what purpose it serves, and so will be able to
find it in an aptly named filter (or think of them as a collection). If
he truly has no idea where it might be, then there is probably no help
for him, short of some sort of sketch-and-search, which would be one
smashing great idea, but is probably technically unfeasable.
Do that as a user-installable extension.
Sure. No reason not to. That would be a first step. Although I don't
see why it couldn't be part of the core LO, but no, it wouldn't have to
What happens when the ohm symbol is not in the set of "Electrical
Symbols"? Joe Sixpack is even more lost than under the current setup.
Well, then he either needs to do an exhaustive manual search, or
download a more complete filter/collection. Or amend it himself.
And if your font is webdings or whatever, and the character for ohm
doesn't look like an ohm, then you will get a pumpkin, or whatever,
Then you are back with the mess that fonts were, before most software
incorporated, and could utilize Unicode.
That has nothing to do with this idea, that problem exists all on its
own. You try webdings in the current Special Characters dialog and tell
me that the problem would be purely in my extension.
What happens when the programmer omits glyphs because s/he thinks that
they are so rare/obscure that they will not be useḍ?
As I stated, download a more complete filter/collection, or make one
yourself. Chances are that any offical ones would be fairly complete to
start with, but the whole point of my system (which is just how I
envision the OP's enhancement idea) is that it would be extensible.
I really should have called it a collection, rather than a filter, that
might have avoided some confusion.
To unsubscribe e-mail to: email@example.com
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-users] Feature Request - Categories for special characters · Kracked_P_P---webmaster
Re: [libreoffice-users] Feature Request - Categories for special characters · Regina Henschel
- Re: [libreoffice-users] Feature Request - Categories for special characters (continued)
Impressum (Legal Info)
: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (MPLv2
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our trademark policy