Mail Archives: geda-user/2014/09/15/01:22:03
--001a113637d01151cf050313cf72
Content-Type: text/plain; charset=UTF-8
I don't particularly mind if the final solution employs stroke -> PCB
derived fonts instead of my initial symbol set. Obviously, stroke -> symbol
derived fonts are going to be nicer to look at. It was an interesting
exercise for me whether or not the symbols eventually get used.
Nevertheless, I think having something available in the interim for people
needing a few glyphs here or there is better nothing, and I was primarily
hoping that by providing a full CJK symbol set it would provide some
impetus to implementing unicode support.
Which CJK symbol set should ideally be used is not the rate limiting step
here, unicode support within symbol definitions is.
Cheers,
Erich.
On Mon, Sep 15, 2014 at 2:08 PM, <mskala AT ansuz DOT sooke DOT bc DOT ca> wrote:
> On Mon, 15 Sep 2014, Erich Heinzle wrote:
> > Anything that increases the potential user base by > 1 billion has got
> to be
> > a good thing.
>
> I think that's a bit of an exaggeration. For it to be true, lack of this
> feature would have to be stopping the ENTIRE population of China from
> becoming users of the software, and be the ONLY thing stopping them.
>
> Do we have any indication that anybody actually wants to put what comes
> out of bitmap-to-stroke conversion from low-res Chinese bitmap fonts onto
> a PCB at all?
>
> I maintain a Japanese-language stroked font project
> (tsukurimashou.sourceforge.jp). My project wouldn't be suitable for
> Chinese and doesn't really have full character coverage for any CJK
> language; but other projects do provide stroke data for these kinds of
> characters with better coverage. It doesn't have to come from bitmap
> conversion. I'm most familiar with the Japanese-language ones, which
> include the Hershey fonts from the 1960s (incomplete coverage,
> unfortunately); KanjiVG (complete coverage of Japanese in SVG format -
> these would probably be easiest to convert for gEDA use); and Wadalab (the
> original source of many of the Asian-language fonts shipped in Linux
> distributions to this day). Chinese-language projects of similar nature
> do exist.
>
> If someone wanted to put stroked CJK characters onto a PCB, I think they'd
> be much happier using something derived from one of those sources, instead
> of from an attempt at converting low-res bitmaps back to strokes.
> Low-res bitmaps always contain significant compromises of the basic
> geometry of the characters, in order to get them to fit the grid at all.
> As a simple English-language example, in some of my terminal windows a
> lowercase "m" appears as just a solid rectangle, because there isn't
> enough horizontal resolution in the low-res bitmap to render the three
> vertical strokes separately with nice spacing. That's readable in its
> correct context, but imagine what it would look like, and whether it would
> be acceptable, after being converted "back" to strokes. CJK bitmap fonts
> are rife with such cases. That's why doing the conversion in the other
> direction, from strokes to bitmaps, is a largely manual process despite
> the expense of doing it at the scale of these character sets: knowing
> where to make the compromises is a very difficult thing to automate.
>
> --
> Matthew Skala
> mskala AT ansuz DOT sooke DOT bc DOT ca People before principles.
> http://ansuz.sooke.bc.ca/
>
--001a113637d01151cf050313cf72
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>I don't particularly mind if the final solut=
ion employs stroke -> PCB derived fonts instead of my initial symbol set=
. Obviously, stroke -> symbol derived fonts are going to be nicer to loo=
k at. It was an interesting exercise for me whether or not the symbols even=
tually get used.<br><br></div><div>Nevertheless, I think having something a=
vailable in the interim for people needing a few glyphs here or there is be=
tter nothing, and I was primarily hoping that by providing a full CJK symbo=
l set it would provide some impetus to implementing unicode support.<br></d=
iv><br>Which CJK symbol set should ideally be used is not the rate limiting=
step here, unicode support within symbol definitions is.<br><br></div><div=
>Cheers,<br><br>Erich.<br></div></div><div class=3D"gmail_extra"><br><br><d=
iv class=3D"gmail_quote">On Mon, Sep 15, 2014 at 2:08 PM, <span dir=3D"ltr=
"><<a href=3D"mailto:mskala AT ansuz DOT sooke DOT bc DOT ca" target=3D"_blank">mskala@=
ansuz.sooke.bc.ca</a>></span> wrote:<br><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
span class=3D"">On Mon, 15 Sep 2014, Erich Heinzle wrote:<br>
> Anything that increases the potential user base by > 1 billion has =
got to be<br>
> a good thing.<br>
<br>
</span>I think that's a bit of an exaggeration.=C2=A0 For it to be true=
, lack of this<br>
feature would have to be stopping the ENTIRE population of China from<br>
becoming users of the software, and be the ONLY thing stopping them.<br>
<br>
Do we have any indication that anybody actually wants to put what comes<br>
out of bitmap-to-stroke conversion from low-res Chinese bitmap fonts onto<b=
r>
a PCB at all?<br>
<br>
I maintain a Japanese-language stroked font project<br>
(<a href=3D"http://tsukurimashou.sourceforge.jp" target=3D"_blank">tsukurim=
ashou.sourceforge.jp</a>).=C2=A0 My project wouldn't be suitable for<br=
>
Chinese and doesn't really have full character coverage for any CJK<br>
language; but other projects do provide stroke data for these kinds of<br>
characters with better coverage.=C2=A0 It doesn't have to come from bit=
map<br>
conversion.=C2=A0 I'm most familiar with the Japanese-language ones, wh=
ich<br>
include the Hershey fonts from the 1960s (incomplete coverage,<br>
unfortunately); KanjiVG (complete coverage of Japanese in SVG format -<br>
these would probably be easiest to convert for gEDA use); and Wadalab (the<=
br>
original source of many of the Asian-language fonts shipped in Linux<br>
distributions to this day).=C2=A0 Chinese-language projects of similar natu=
re<br>
do exist.<br>
<br>
If someone wanted to put stroked CJK characters onto a PCB, I think they=
9;d<br>
be much happier using something derived from one of those sources, instead<=
br>
of from an attempt at converting low-res bitmaps back to strokes.<br>
Low-res bitmaps always contain significant compromises of the basic<br>
geometry of the characters, in order to get them to fit the grid at all.<br=
>
As a simple English-language example, in some of my terminal windows a<br>
lowercase "m" appears as just a solid rectangle, because there is=
n't<br>
enough horizontal resolution in the low-res bitmap to render the three<br>
vertical strokes separately with nice spacing.=C2=A0 That's readable in=
its<br>
correct context, but imagine what it would look like, and whether it would<=
br>
be acceptable, after being converted "back" to strokes.=C2=A0 CJK=
bitmap fonts<br>
are rife with such cases.=C2=A0 That's why doing the conversion in the =
other<br>
direction, from strokes to bitmaps, is a largely manual process despite<br>
the expense of doing it at the scale of these character sets:=C2=A0 knowing=
<br>
where to make the compromises is a very difficult thing to automate.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Matthew Skala<br>
<a href=3D"mailto:mskala AT ansuz DOT sooke DOT bc DOT ca">mskala AT ansuz DOT sooke DOT bc DOT ca</a>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0People before pr=
inciples.<br>
<a href=3D"http://ansuz.sooke.bc.ca/" target=3D"_blank">http://ansuz.sooke.=
bc.ca/</a><br>
</font></span></blockquote></div><br></div>
--001a113637d01151cf050313cf72--
- Raw text -