Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.acorn.misc > #4598 > unrolled thread

Increasing default line spacing in RISC OS fonts

Back to article view | Back to comp.sys.acorn.misc

Contents

  Increasing default line spacing in RISC OS fonts castlevarich <castlevarich@yahoo.co.uk> - 2012-03-24 05:17 -0700
    Re: Increasing default line spacing in RISC OS fonts Jim Nagel <jimnewsm10d@abbeypress.co.uk> - 2012-03-26 22:27 +0100
      Re: Increasing default line spacing in RISC OS fonts Stewart Brodie <stewart.brodie@ntlworld.com> - 2012-03-26 22:42 +0100
        Re: Increasing default line spacing in RISC OS fonts Martin Wuerthner <spamtrap@mw-software.com> - 2012-03-27 00:18 +0200
          Re: Increasing default line spacing in RISC OS fonts castlevarich <castlevarich@yahoo.co.uk> - 2012-04-04 08:39 -0700
            Re: Increasing default line spacing in RISC OS fonts Russell Hafter News <see.sig@walkingingermany.invalid> - 2012-04-04 20:27 +0100
            Re: Increasing default line spacing in RISC OS fonts Martin Wuerthner <spamtrap@mw-software.com> - 2012-04-05 01:17 +0200
              Re: Increasing default line spacing in RISC OS fonts castlevarich <castlevarich@yahoo.co.uk> - 2012-04-05 08:38 -0700
                Re: Increasing default line spacing in RISC OS fonts Martin Wuerthner <spamtrap@mw-software.com> - 2012-04-05 18:10 +0200
                  Re: Increasing default line spacing in RISC OS fonts castlevarich <castlevarich@yahoo.co.uk> - 2012-04-16 08:42 -0700
                    Re: Increasing default line spacing in RISC OS fonts Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-04-18 07:24 +0100
                      Re: Increasing default line spacing in RISC OS fonts Martin Wuerthner <spamtrap@mw-software.com> - 2012-04-18 17:06 +0200
                        Re: Increasing default line spacing in RISC OS fonts Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-04-18 18:55 +0100
                          Re: Increasing default line spacing in RISC OS fonts Martin Wuerthner <spamtrap@mw-software.com> - 2012-04-19 11:09 +0200
                            Re: Increasing default line spacing in RISC OS fonts Russell Hafter News <see.sig@walkingingermany.invalid> - 2012-04-19 10:37 +0100
                            Re: Increasing default line spacing in RISC OS fonts Paul Sprangers <Paul@sprie.nl> - 2012-04-19 11:48 +0200
                              Re: Increasing default line spacing in RISC OS fonts Martin Wuerthner <spamtrap@mw-software.com> - 2012-04-19 16:39 +0200
                                Re: Increasing default line spacing in RISC OS fonts Paul Sprangers <Paul@sprie.nl> - 2012-04-20 00:22 +0200
                                  Re: Increasing default line spacing in RISC OS fonts Martin Wuerthner <spamtrap@mw-software.com> - 2012-04-20 11:10 +0200
                                    Re: Increasing default line spacing in RISC OS fonts Paul Sprangers <Paul@sprie.nl> - 2012-04-20 15:50 +0200
                                      Re: Increasing default line spacing in RISC OS fonts Martin Wuerthner <spamtrap@mw-software.com> - 2012-04-20 17:10 +0200
                                        Re: Increasing default line spacing in RISC OS fonts Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-04-20 18:06 +0200
                                          Re: Increasing default line spacing in RISC OS fonts "John Williams (News)" <UCEbin@tiscali.co.uk> - 2012-04-20 18:31 +0200
                                          Re: Increasing default line spacing in RISC OS fonts druck <news@druck.org.uk> - 2012-04-20 22:21 +0100
                                            Re: Increasing default line spacing in RISC OS fonts Stewart Brodie <stewart.brodie@ntlworld.com> - 2012-04-21 02:15 +0100
                                            Re: Increasing default line spacing in RISC OS fonts Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-04-21 05:06 +0200
                                      Re: Increasing default line spacing in RISC OS fonts Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-04-20 17:54 +0200
                                    Re: Increasing default line spacing in RISC OS fonts Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-04-20 17:47 +0200
                                      Re: Increasing default line spacing in RISC OS fonts Martin Wuerthner <spamtrap@mw-software.com> - 2012-04-23 08:00 +0200
                                        Re: Increasing default line spacing in RISC OS fonts Paul Sprangers <Paul@sprie.nl> - 2012-04-23 10:16 +0200
                              Re: Increasing default line spacing in RISC OS fonts Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-04-19 17:00 +0200
                            Re: Increasing default line spacing in RISC OS fonts Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-04-20 23:30 +0100
                        Re: Increasing default line spacing in RISC OS fonts castlevarich <castlevarich@yahoo.co.uk> - 2012-04-21 04:38 -0700

Page 1 of 2  [1] 2  Next page →

#4598 — Increasing default line spacing in RISC OS fonts

Hi, everybody.

I'm trying to modify a font in DrFonty
to add some extra accented characters.

Unfortunately, when I try to use the
font, it looks quite unpleasant, because
the lines are too close together, making
it appear very dense and unappealing.

Does anybody know how to increase the
default line spacing for a font in DrFonty,
or any other font editing program    ??????

Jon Robinson, Leeds

[toc] | [next] | [standalone]

#4615

castlevarich  wrote on 24 Mar:
> Does anybody know how to increase the default line spacing for a font
> in DrFonty, or any other font editing program    ?

You say that when you use the font the lines are too close together.  
The control for linespacing is in the application displaying it rather 
than in the font itself.  For example:

   in !Edit: menu, Display > Linespacing
   in Impression: Effect > Linespacing  (or Sh-Ctrl-L on a selection 
of text), or use its Style editor and change the Normala style

Another angle on your question:  When you use the original font, 
without the extra characters you made for it, how was the linespacing 
then?


-- 
Jim Nagel                        www.archivemag.co.uk

[toc] | [prev] | [next] | [standalone]

#4616

Jim Nagel <jimnewsm10d@abbeypress.co.uk> wrote:

> castlevarich  wrote on 24 Mar:
> > Does anybody know how to increase the default line spacing for a font
> > in DrFonty, or any other font editing program    ?
> 
> You say that when you use the font the lines are too close together.  
> The control for linespacing is in the application displaying it rather 
> than in the font itself.

Fonts can have a leading built-in to the font metrics, which should have an
effect on the distance between successive baselines.  

(Although, I'm afraid it's been very many years since I've looked at RISC OS
fonts, so that might be the case for them, I suppose, but it would be
strange if not)


-- 
Stewart Brodie

[toc] | [prev] | [next] | [standalone]

#4617

In message <gemini.m1ihmk000uy0a0ieo.stewart.brodie@ntlworld.com>
          Stewart Brodie <stewart.brodie@ntlworld.com> wrote:

> Jim Nagel <jimnewsm10d@abbeypress.co.uk> wrote:

>> castlevarich  wrote on 24 Mar:
>>> Does anybody know how to increase the default line spacing for a font
>>> in DrFonty, or any other font editing program    ?
>> 
>> You say that when you use the font the lines are too close together.
>> The control for linespacing is in the application displaying it rather
>> than in the font itself.

> Fonts can have a leading built-in to the font metrics, which should have an
> effect on the distance between successive baselines.

You are probably thinking TrueType/PostScript fonts here, which 
feature an "internal leading" value. RISC OS fonts do not have any 
line spacing related global metric information.

RISC OS word processors compute line spacing purely on the basis of 
applied font sizes, ignoring the actual fonts that are used.

Coming back to the original question: Yes, it is possible to force a 
larger line spacing by simply increasing the font's "Design size" 
value. Basically, this value determines how many design units 
correspond to the font's "own" size, so if a program requests a 12pt 
font, then the font is scaled in such a way that "Design size" many 
units measure exactly 12pt.

By increasing the design size, you effectively make all glyphs 
smaller, and that in turn gives the appearance of larger line spacing.

In absolute terms, the line spacing is still the same because that is 
controlled by the word processor, which uses absolute values, but 
since a 12pt type with a larger design size actually comes out 
smaller, the overall effect is that there is more empty space between 
lines.

-- 
Martin
---------------------------------------------------------------------
Martin Wuerthner         MW Software      http://www.mw-software.com/
        RISC OS Software for Design, Printing and Publishing
---------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#4775

On Mar 26, 10:18 pm, Martin Wuerthner <spamt...@mw-software.com>
wrote:
> In message <gemini.m1ihmk000uy0a0ieo.stewart.bro...@ntlworld.com>
>           Stewart Brodie <stewart.bro...@ntlworld.com> wrote:
>
> > Jim Nagel <jimnewsm...@abbeypress.co.uk> wrote:
> >> castlevarich  wrote on 24 Mar:
> >>> Does anybody know how to increase the default line spacing for a font
> >>> in DrFonty, or any other font editing program    ?
>
> >> You say that when you use the font the lines are too close together.
> >> The control for linespacing is in the application displaying it rather
> >> than in the font itself.
> > Fonts can have a leading built-in to the font metrics, which should have an
> > effect on the distance between successive baselines.
>
> You are probably thinking TrueType/PostScript fonts here, which
> feature an "internal leading" value. RISC OS fonts do not have any
> line spacing related global metric information.
>
> RISC OS word processors compute line spacing purely on the basis of
> applied font sizes, ignoring the actual fonts that are used.
>
> Coming back to the original question: Yes, it is possible to force a
> larger line spacing by simply increasing the font's "Design size"
> value. Basically, this value determines how many design units
> correspond to the font's "own" size, so if a program requests a 12pt
> font, then the font is scaled in such a way that "Design size" many
> units measure exactly 12pt.
>
> By increasing the design size, you effectively make all glyphs
> smaller, and that in turn gives the appearance of larger line spacing.
>
> In absolute terms, the line spacing is still the same because that is
> controlled by the word processor, which uses absolute values, but
> since a 12pt type with a larger design size actually comes out
> smaller, the overall effect is that there is more empty space between
> lines.
>
> --
> Martin
> ---------------------------------------------------------------------
> Martin Wuerthner         MW Software      http://www.mw-software.com/
>         RISC OS Software for Design, Printing and Publishing
> ---------------------------------------------------------------------

Dear Herr Wuerthner

In actual fact, the problem seems to be with the old
version of EasiWriter I'm using (7.11), which is about
10 years old.

I am in the process of creating a Latin 2 version of
Trinity, which has all the Central and East European
accents, for use with the new version of Messenger Pro.

However, it's only my copy of EasiWriter which compresses
the lines, when I use the new Latin 2 version of the font.

The line spacing remains the same in Style.

Jon Robinson, Leeds

[toc] | [prev] | [next] | [standalone]

#4777

In article
<c9ddef57-9b60-4d0d-b7c5-82487bfc4a7a@f5g2000vby.googlegroups.com>,
   castlevarich <castlevarich@yahoo.co.uk> wrote:

> In actual fact, the problem seems to be with the old
> version of EasiWriter I'm using (7.11), which is about 10
> years old.

12 actually.
:-)

> I am in the process of creating a Latin 2 version of
> Trinity, which has all the Central and East European
> accents, for use with the new version of Messenger Pro.

I found it easier to just buy a Latin 2 font from EFF, back
in EasiWriter 5 days. No problems at all using this font
with EW.

> However, it's only my copy of EasiWriter which compresses
> the lines, when I use the new Latin 2 version of the font.

What I do notice, though, is when using Pluto set to
iso-8859-2, the cursor is frequently in the wrong place.

The characters are spaced perfectly normally, but the cursor
often lies on top of a character rather than between
characters, which makes editing difficult.

Could it be that the cursor always assumes that characters
are Latin 1, and so, if a Latin 2 character is fatter than
its Latin 1 equivalent (same ASCII code), the cursor is
misplaced?

-- 
Russell
http://www.russell-hafter-holidays.co.uk
Russell Hafter Holidays         E-mail to enquiries at our domain
Need a hotel? <http://www.hrs.com/?client=en__blue&customerId=416873103>

[toc] | [prev] | [next] | [standalone]

#4785

In message <c9ddef57-9b60-4d0d-b7c5-82487bfc4a7a@f5g2000vby.googlegrou 
ps.com>
          castlevarich <castlevarich@yahoo.co.uk> wrote:

> On Mar 26, 10:18 pm, Martin Wuerthner <spamt...@mw-software.com>
> wrote:

>> RISC OS word processors compute line spacing purely on the basis of
>> applied font sizes, ignoring the actual fonts that are used.

Actually, I should have written "RISC OS DTP programs" rather than 
word processors. The above is true for Impression and OvationPro, but 
not for EasiWriter/TechWriter.

> In actual fact, the problem seems to be with the old
> version of EasiWriter I'm using (7.11), which is about
> 10 years old.

> I am in the process of creating a Latin 2 version of
> Trinity, which has all the Central and East European
> accents, for use with the new version of Messenger Pro.

> However, it's only my copy of EasiWriter which compresses
> the lines, when I use the new Latin 2 version of the font.

> The line spacing remains the same in Style.

Yes, the line spacing rules are different in Impression. They are as I 
outlined above: The resulting line spacing is independent of the font.

EasiWriter's default "Auto" linespacing follows a more sophisticated 
rule based on the font's ascent and descent measurements, so the line 
spacing depends on the measurements of the applied font. This is based 
on the behaviour of MS Word. EasiWriter's line spacing mode labelled 
"Exactly" is independent of the font.

I think I can see why the line spacing changes when going from Latin-1 
to Latin-2. EasiWriter uses the Latin-1 E-circumflex glyph to measure 
the font ascent, but in Latin-2 that codepoint happens to be 
E-cedilla, which does not have an accent, so the measured ascent is 
too small. There are much better methods to determine a font's metrics 
nowadays. Unfortunately, that ancient approach cannot be changed 
easily because it would change the layout of existing documents.

-- 
Martin
---------------------------------------------------------------------
Martin Wuerthner         MW Software      http://www.mw-software.com/
        RISC OS Software for Design, Printing and Publishing
---------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#4829

On Apr 4, 11:17 pm, Martin Wuerthner <spamt...@mw-software.com> wrote:
> In message <c9ddef57-9b60-4d0d-b7c5-82487bfc4...@f5g2000vby.googlegrou
> ps.com>
>           castlevarich <castlevar...@yahoo.co.uk> wrote:
>
> > On Mar 26, 10:18 pm, Martin Wuerthner <spamt...@mw-software.com>
> > wrote:
> >> RISC OS word processors compute line spacing purely on the basis of
> >> applied font sizes, ignoring the actual fonts that are used.
>
> Actually, I should have written "RISC OS DTP programs" rather than
> word processors. The above is true for Impression and OvationPro, but
> not for EasiWriter/TechWriter.
>
> > In actual fact, the problem seems to be with the old
> > version of EasiWriter I'm using (7.11), which is about
> > 10 years old.
> > I am in the process of creating a Latin 2 version of
> > Trinity, which has all the Central and East European
> > accents, for use with the new version of Messenger Pro.
> > However, it's only my copy of EasiWriter which compresses
> > the lines, when I use the new Latin 2 version of the font.
> > The line spacing remains the same in Style.
>
> Yes, the line spacing rules are different in Impression. They are as I
> outlined above: The resulting line spacing is independent of the font.
>
> EasiWriter's default "Auto" linespacing follows a more sophisticated
> rule based on the font's ascent and descent measurements, so the line
> spacing depends on the measurements of the applied font. This is based
> on the behaviour of MS Word. EasiWriter's line spacing mode labelled
> "Exactly" is independent of the font.
>
> I think I can see why the line spacing changes when going from Latin-1
> to Latin-2. EasiWriter uses the Latin-1 E-circumflex glyph to measure
> the font ascent, but in Latin-2 that codepoint happens to be
> E-cedilla, which does not have an accent, so the measured ascent is
> too small. There are much better methods to determine a font's metrics
> nowadays. Unfortunately, that ancient approach cannot be changed
> easily because it would change the layout of existing documents.
>
> --
> Martin
> ---------------------------------------------------------------------
> Martin Wuerthner         MW Software      http://www.mw-software.com/
>         RISC OS Software for Design, Printing and Publishing
> ---------------------------------------------------------------------

Hi, Martin & Russell.

The reason I'm trying to create a modified version of Trinity, is that
I want to make it available for free download, bundled with a couple
of
keyboard drivers, probably for Czech and Polish, in time for the
next version of Messenger, which will understand encodings other
than Latin 1.

I haven't tried this yet, but I wonder if it's possible to put an
invisible
object in the font definition at the E-circumflex position, which will
heighten the character, without affecting its appearance.

Jon Robinson, Leeds

[toc] | [prev] | [next] | [standalone]

#4831

In message <88805743-f3e8-410c-b7da-5292744cb7a2@l7g2000vbw.googlegrou 
ps.com>
          castlevarich <castlevarich@yahoo.co.uk> wrote:

> The reason I'm trying to create a modified version of Trinity, is that
> I want to make it available for free download, bundled with a couple
> of keyboard drivers, probably for Czech and Polish, in time for the
> next version of Messenger, which will understand encodings other
> than Latin 1.

Such a modified version of Trinity should not be necessary.

The standard Trinity ROM font does have all the Latin1 AND Latin2 
glyphs, plus many others. Creating a Latin2-only variant downgrades 
the font from its current multi-encoding setup to a single fixed 
encoding. That only make sense if you want to use this font with 
applications that do not know about encodings (i.e., pretty much all 
of them, most notably all RISC OS word processors and DTP programs).

A new encodings-aware version of MPro would be the one piece of 
software for which you would not need such a fixed encoding font 
because it could easily use the standard Trinity font in ROM to 
display Latin-2 text without anyone having to install a modified 
version of the font.

-- 
Martin
---------------------------------------------------------------------
Martin Wuerthner         MW Software      http://www.mw-software.com/
        RISC OS Software for Design, Printing and Publishing
---------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#4934

On Apr 5, 4:10 pm, Martin Wuerthner <spamt...@mw-software.com> wrote:
> In message <88805743-f3e8-410c-b7da-5292744cb...@l7g2000vbw.googlegrou
> ps.com>
>           castlevarich <castlevar...@yahoo.co.uk> wrote:
>
> > The reason I'm trying to create a modified version of Trinity, is that
> > I want to make it available for free download, bundled with a couple
> > of keyboard drivers, probably for Czech and Polish, in time for the
> > next version of Messenger, which will understand encodings other
> > than Latin 1.
>
> Such a modified version of Trinity should not be necessary.
>
> The standard Trinity ROM font does have all the Latin1 AND Latin2
> glyphs, plus many others. Creating a Latin2-only variant downgrades
> the font from its current multi-encoding setup to a single fixed
> encoding. That only make sense if you want to use this font with
> applications that do not know about encodings (i.e., pretty much all
> of them, most notably all RISC OS word processors and DTP programs).
>
> A new encodings-aware version of MPro would be the one piece of
> software for which you would not need such a fixed encoding font
> because it could easily use the standard Trinity font in ROM to
> display Latin-2 text without anyone having to install a modified
> version of the font.
>
> --
> Martin
> ---------------------------------------------------------------------
> Martin Wuerthner         MW Software      http://www.mw-software.com/
>         RISC OS Software for Design, Printing and Publishing
> ---------------------------------------------------------------------

I can now confirm that putting an invisible line in with the E-
circumflex character DOES increase the line spacing to normal again in
EasiWriter.

I'm creating the Latin-2 version of Trinity because I don't like using
the Alphabet command at the command line, and I also want to be able
to read and write Latin-2 RTF files.

Herr Wuerthner, how difficult would it be to add an encoding tag to
Word and RTF files, when you save them from EasiWriter ???

I've already nearly finished Latin-2, Russian and Greek encoded RISC
OS fonts, which will work with the relevant keyboard drivers, and I'm
hoping that they will soon be available for free download, so there is
some point in doing it.

Jon Robinson, Leeds

[toc] | [prev] | [next] | [standalone]

#4958

In message <10cb91e2-30ed-4524-bae8-7e7f479a9afd@w5g2000vbp.googlegroups.com>
 on 16 Apr 2012 castlevarich  wrote:

> I'm creating the Latin-2 version of Trinity because I don't like using the
> Alphabet command at the command line, and I also want to be able to read
> and write Latin-2 RTF files.
> 
> Herr Wuerthner, how difficult would it be to add an encoding tag to
> Word and RTF files, when you save them from EasiWriter ???

So it sounds as though what you are creating is a Latin-1 font where the
shapes of the characters match up with the equivalent code points in Latin-2.

That's no way that I know of that an application (even if it were fully aware
of encodings and so on) could tell that an individual font has character
shapes belonging to a different encoding.

Therefore, while your approach might work for you personally in creating
and printing files, and in making Latin-2 RTF files look right when loaded
into RISC OS applications, the applications themselves won't be any the
wiser.  And as soon as you export the text to any application which does not
allow setting a font (e.g. a text editor, e-mail software, database) the
Latin-2 shaped characters will all go wrong.

Because the application cannot know what shape the characters are, Martin
could not modify EasWriter to output the appropriate encoding declaration in
an RTF file exported from EasiWriter.  Not without having a list of fonts
that behave like that, but that's frankly unsustainable.  What happens when
the user decides to change font mid-document to include Latin-1 characters as
well, as people are bound to do?  If Martin is going to invest time in this
area he is sure to want to do the job properly, and the existing ROM fonts
will be fine for this.

You yourself could quite easily edit the RTF header manually in any RTF files
you export by using a text editor.  That's probably the best solution for
what you want to do until a proper encodings-aware word processor comes
along.

-- 
Matthew Phillips
Durham

[toc] | [prev] | [next] | [standalone]

#4964

In message <9e27368252.Matthew@sinenomine.freeserve.co.uk>
          Matthew Phillips <spam2011m@yahoo.co.uk> wrote:

> In message <10cb91e2-30ed-4524-bae8-7e7f479a9afd@w5g2000vbp.googlegroups.com>
>  on 16 Apr 2012 castlevarich  wrote:

>> I'm creating the Latin-2 version of Trinity because I don't like using the
>> Alphabet command at the command line, and I also want to be able to read
>> and write Latin-2 RTF files.
>> 
>> Herr Wuerthner, how difficult would it be to add an encoding tag to
>> Word and RTF files, when you save them from EasiWriter ???

> So it sounds as though what you are creating is a Latin-1 font where the
> shapes of the characters match up with the equivalent code points in Latin-2.

> That's no way that I know of that an application (even if it were fully aware
> of encodings and so on) could tell that an individual font has character
> shapes belonging to a different encoding.
> [...]

That problem does not occur if the font is created correctly. 
Applications can tell how fonts are encoded. The only exception are 
legacy RISC OS 2 fonts that do not have an encoding. Such fonts are 
assumed to be in the system encoding (usually Latin-1).

So, the problem you describe would only be there if Jon chose to 
create an encodingless legacy RISC OS 2 font (from which I would 
strongly discourage him), or if he chose to create a font with Latin-2 
glyphs that actually claimed it was Latin-1 encoded (which would not 
make any sense).

The idea of offering a Latin-2 encoded font is not new. EFF have done 
so for more than a decade. That does not mean that applications really 
take notice of the encoding, but that is not the font's fault.

-- 
Martin
---------------------------------------------------------------------
Martin Wuerthner         MW Software      http://www.mw-software.com/
        RISC OS Software for Design, Printing and Publishing
---------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#4966

In message <7eee658252.martin@bach.planiverse.com>
 on 18 Apr 2012 Martin Wuerthner  wrote:

> In message <9e27368252.Matthew@sinenomine.freeserve.co.uk>
>           Matthew Phillips <spam2011m@yahoo.co.uk> wrote:
> 
> > In message <10cb91e2-30ed-4524-bae8-7e7f479a9afd@w5g2000vbp.googlegroups.com>
> >  on 16 Apr 2012 castlevarich  wrote:
> 
> >> I'm creating the Latin-2 version of Trinity because I don't like using the
> >> Alphabet command at the command line, and I also want to be able to read
> >> and write Latin-2 RTF files.
> >> 
> >> Herr Wuerthner, how difficult would it be to add an encoding tag to
> >> Word and RTF files, when you save them from EasiWriter ???
> 
> > So it sounds as though what you are creating is a Latin-1 font where the
> > shapes of the characters match up with the equivalent code points in Latin-2.
> 
> > That's no way that I know of that an application (even if it were fully aware
> > of encodings and so on) could tell that an individual font has character
> > shapes belonging to a different encoding.
> > [...]
> 
> That problem does not occur if the font is created correctly. 
> Applications can tell how fonts are encoded. The only exception are 
> legacy RISC OS 2 fonts that do not have an encoding. Such fonts are 
> assumed to be in the system encoding (usually Latin-1).
> 
> So, the problem you describe would only be there if Jon chose to 
> create an encodingless legacy RISC OS 2 font (from which I would 
> strongly discourage him), or if he chose to create a font with Latin-2 
> glyphs that actually claimed it was Latin-1 encoded (which would not 
> make any sense).
> 
> The idea of offering a Latin-2 encoded font is not new. EFF have done 
> so for more than a decade. That does not mean that applications really 
> take notice of the encoding, but that is not the font's fault.

Thanks: I stand corrected.

I must have a look into the PRMs to get a better understanding of what
happens if an application uses Font_FindFont without specifying an encoding,
and what happens if it calls Font_FindFont specifying an encoding not
supported by a font.

I'm afraid I had assumed that if an application is running in a Latin-1
environment and calls Font_FindFont without giving an encoding, then the font
handle returned would suit the current alphabet, but perhaps it just returns
the default encoding for a font?

Time to do some reading....

-- 
Matthew Phillips
Durham

[toc] | [prev] | [next] | [standalone]

#4971

In message <367a758252.Matthew@sinenomine.freeserve.co.uk>
          Matthew Phillips <spam2011m@yahoo.co.uk> wrote:

> I must have a look into the PRMs to get a better understanding of what
> happens if an application uses Font_FindFont without specifying an encoding,
> and what happens if it calls Font_FindFont specifying an encoding not
> supported by a font.

> I'm afraid I had assumed that if an application is running in a Latin-1
> environment and calls Font_FindFont without giving an encoding, then the font
> handle returned would suit the current alphabet, but perhaps it just returns
> the default encoding for a font?

Either can happen, depending on whether the font is a "language" font 
based on a base encoding (i.e., with an "IntMetrics<N>" file) or a 
"symbol" font with an "IntMetrics" file. Only "language" fonts are 
mapped to the system alphabet (strictly speaking, to the current 
alphabet with the Unicode FontManager or the territory default 
alphabet with the traditional FontManager). The behaviour for 
"language" fonts is not relevant in this scenario though because the 
kind of Latin-2 Jon wants to create could not be a "language" font.

With the notable exception of the 3 ROM language fonts, most RISC OS 
fonts are "symbol" fonts in the above sense. For instance, a typical 
EFF Latin-1 font comes with an IntMetrics file and an Encoding file 
describing the font's encoding (in this example, EFF Latin1, which is 
a superset of ISO Latin1, but different from Acorn Latin1). An EFF 
Latin-2 font comes with a Latin-2 Encoding file (presumably, I have 
not seen one yet).

If Jon did create a "language" font containing just the Latin-2 
glyphs, then this would not have the effect he wanted. Opening it 
without specifying an encoding on a Latin-1 system with the Unicode 
FontManager would result in a Latin-1 encoded font, but then, only the 
Latin-1 subset of the font's glyphs would be accessible and they would 
be at their Latin-1 codepoints, so the effect would be a font for a 
subset of Latin-1 instead of a Latin-2 font.

To achieve the desired effect (a font that turns out to be Latin-2 
encoded when being opened without specifying an encoding) he would 
have to create a "symbol" font, i.e., a font with an "IntMetrics" file 
(and, hopefully, a local encodings file, otherwise, PostScript 
printing would go wrong), and in that case, the current system 
alphabet would not be relevant when opening it without specifying an 
encoding. So, the result would be a Latin-2 encoded font.

To see the difference between opening a font without an encoding and 
with an explicit Latin-1 encoding, try XChars and view an EFF font in 
"Default" (i.e., no encoding specified, just as most applications do) 
and "Latin1" encodings. The layout of the font changes because it is a 
"symbol" font, so it is opened in "Glyph" encoding by default. Nothing 
changes with "Homerton" because it is opened in Latin-1 by default. 
Try viewing Homerton with an explicit "Greek" encoding - that maps the 
one Greek character Homerton has (the "mu") in the correct place for 
Greek, but leaves the other Greek characters empty because the font 
does not have them. You would see the same effect with a Latin-2 
"language" font.

> Time to do some reading....

In addition to the PRMs it is worth while reading the RO5 FontManager 
document, section 2.2 "Default encodings."

-- 
Martin
---------------------------------------------------------------------
Martin Wuerthner         MW Software      http://www.mw-software.com/
        RISC OS Software for Design, Printing and Publishing
---------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#4972

In article <8616c98252.martin@bach.planiverse.com>, Martin
Wuerthner <spamtrap@mw-software.com> wrote:

> An EFF Latin-2 font comes with a Latin-2 Encoding file
> (presumably, I have not seen one yet).

My EFF latin-2 version of Quorum has five different weights.
Each weight has the following files: Type1, IntMetrics,
Outlines, AFM and Encoding.

The encoding includes names of the characters: eg.
/dmacron /nacute /ncaron /oacute
/ocircumflex /ohungarumlaut /odieresis /divide
/rcaron /uring /uacute /uhungarumlaut
/udieresis /yacute /tcedilla /dotaccent
which, I assume, are PostScript names?

-- 
Russell
http://www.russell-hafter-holidays.co.uk
Russell Hafter Holidays         E-mail to enquiries at our domain
Need a hotel? <http://www.hrs.com/?client=en__blue&customerId=416873103>

[toc] | [prev] | [next] | [standalone]

#4973

In article <8616c98252.martin@bach.planiverse.com>,
   Martin Wuerthner <spamtrap@mw-software.com> wrote:

> Try viewing Homerton with an explicit "Greek" encoding - that maps the 
> one Greek character Homerton has (the "mu") in the correct place for 
> Greek, but leaves the other Greek characters empty because the font 
> does not have them.

At the risk of drifting off the topic, why doesn't !XChars display the
cyrillic characters of a unicode font when viewed in cyrillic encoding,
while all other encodings show the full set of appropriate characters?

I've tried ArialUni, Arial.Regular and Times.Regular, all of which have a
an extensive set of cyrillic characters.

At the risk of drifting off even further, is there any chance that you,
Martin, or anyone else is going to develop a fully unicode aware RISC OS?

Kind regards,
Paul Sprangers

[toc] | [prev] | [next] | [standalone]

#4975

In message <5282ccb375Paul@sprie.nl>
          Paul Sprangers <Paul@sprie.nl> wrote:

> In article <8616c98252.martin@bach.planiverse.com>,
>    Martin Wuerthner <spamtrap@mw-software.com> wrote:

>> Try viewing Homerton with an explicit "Greek" encoding - that maps the
>> one Greek character Homerton has (the "mu") in the correct place for
>> Greek, but leaves the other Greek characters empty because the font
>> does not have them.

> At the risk of drifting off the topic, why doesn't !XChars display the
> cyrillic characters of a unicode font when viewed in cyrillic encoding,
> while all other encodings show the full set of appropriate characters?

I just tried and it works fine here with a Cyberbit conversion I made 
in 2009 (which created a "symbol" font with a local Encoding vector). 
The conversion must be made against the local UTF8 encoding vector 
because that vector, and consequently the Cyrillic encoding supplied 
with RISC OS 5, uses artificial number-based glyph names for the 
Cyrillic characters instead of the glyph names from the Adobe Glyph 
List. Maybe your Unicode font does not have a valid encoding vector or 
maybe it is based on an obsolete conversion approach that generated a 
new base encoding? In the latter case the font would have an 
IntMetrics<n> file.

> At the risk of drifting off even further, is there any chance that you,
> Martin, or anyone else is going to develop a fully unicode aware RISC OS?

You would need to clarify what exactly you mean by that. What kind of 
OS-level Unicode functionality are you missing? You can put RISC OS 
into Unicode mode by setting the system alphabet to UTF8 (which means 
Unicode filenames, Unicode keypresses sent to applications by the 
Wimp, etc.), but most applications are not happy with that. So, it is 
mainly the applications that are the problem. Some areas of the OS are 
not fully Unicode aware, but that does not really make much of a 
difference as long as you cannot really put the system into Unicode 
mode in the first place because applications cannot cope.

-- 
Martin
---------------------------------------------------------------------
Martin Wuerthner         MW Software      http://www.mw-software.com/
        RISC OS Software for Design, Printing and Publishing
---------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#4989

In article <e759e78252.martin@bach.planiverse.com>,
   Martin Wuerthner <spamtrap@mw-software.com> wrote:

> > At the risk of drifting off the topic, why doesn't !XChars display the
> > cyrillic characters of a unicode font when viewed in cyrillic encoding,
> > while all other encodings show the full set of appropriate characters?

> I just tried and it works fine here with a Cyberbit conversion I made 
> in 2009 (which created a "symbol" font with a local Encoding vector). 
> The conversion must be made against the local UTF8 encoding vector 
> because that vector, and consequently the Cyrillic encoding supplied 
> with RISC OS 5, uses artificial number-based glyph names for the 
> Cyrillic characters instead of the glyph names from the Adobe Glyph 
> List. Maybe your Unicode font does not have a valid encoding vector or 
> maybe it is based on an obsolete conversion approach that generated a 
> new base encoding? In the latter case the font would have an 
> IntMetrics<n> file.

My version of Cyberbit doesn't display the cyrillic characters as well.
All of the unicode fonts that I use are converted with John-Mark Bell's
!TTF2f and their cyrillic characters seem to work fine, at least in
!NetSurf as well as in !Dict. As said before, all other encodings that are
supported by !XChars display their characters properly.

I'm afraid that I don't understand a bit of what you explain about
artificial number-based glyphs and all that, but I can assure that none of
the unicode fonts here have an IntMetrics<n> file. Actually, I don't think
that I've ever seen such file.


> > At the risk of drifting off even further, is there any chance that
> > you, Martin, or anyone else is going to develop a fully unicode aware
> > RISC OS?

> You would need to clarify what exactly you mean by that. What kind of 
> OS-level Unicode functionality are you missing? You can put RISC OS 
> into Unicode mode by setting the system alphabet to UTF8 (which means 
> Unicode filenames, Unicode keypresses sent to applications by the 
> Wimp, etc.), but most applications are not happy with that. So, it is 
> mainly the applications that are the problem. Some areas of the OS are 
> not fully Unicode aware, but that does not really make much of a 
> difference as long as you cannot really put the system into Unicode 
> mode in the first place because applications cannot cope.

That more or less describes the dead end in which RISC OS currently is
trapped, at least when it comes to unicode. I really would like to be able
to use unicode fonts in, say, OvationPro, and to send e-mails is different
encodings, for which I have to switch to our Windows laptop now.

At the moment, I can at least read cyrillic e-mails on my loyal Iyonix, by
dumping their contents into !Edit, that I pushed to use the ArialUni\EUTF8
font. One of the very first steps towards a more convenient unicode aware
system would be the ability to choose fonts with this \EUTF8 extension
directly from the appropriate menus rather than configuring them in text
based boot files or worse. And while !Edit is able to display unicode
indeed, editing is a real nightmare and printing is completely out of the
question. But probably you're right: it's merely a matter of updating the
applications rather than rewriting the OS. Will it ever happen?

Kind regards,
Paul Sprangers

[toc] | [prev] | [next] | [standalone]

#4998

In message <528311b64cPaul@sprie.nl>
          Paul Sprangers <Paul@sprie.nl> wrote:

>>> At the risk of drifting off even further, is there any chance that
>>> you, Martin, or anyone else is going to develop a fully unicode aware
>>> RISC OS?

>> You would need to clarify what exactly you mean by that. What kind of
>> OS-level Unicode functionality are you missing? You can put RISC OS
>> into Unicode mode by setting the system alphabet to UTF8 (which means
>> Unicode filenames, Unicode keypresses sent to applications by the
>> Wimp, etc.), but most applications are not happy with that. So, it is
>> mainly the applications that are the problem. Some areas of the OS are
>> not fully Unicode aware, but that does not really make much of a
>> difference as long as you cannot really put the system into Unicode
>> mode in the first place because applications cannot cope.

> That more or less describes the dead end in which RISC OS currently is
> trapped, at least when it comes to unicode. I really would like to be able
> to use unicode fonts in, say, OvationPro, and to send e-mails is different
> encodings, for which I have to switch to our Windows laptop now.

Of course, but there is nothing that needs to be changed in RISC OS to 
allow that, so if that is what you want, then you need to ask a 
different question. Instead of asking for an improved OS you need to 
ask for Unicode aware applications. Improving the Unicode support in 
the OS will not make any difference at all as long as applications are 
refusing to go Unicode.

This is not a chicken-and-egg situation because the existing Unicode 
support is good enough to display, process and print Unicode text 
(PostScript printing requires the PostScript 3 driver - credits to 
John Tytgat for doing all the Unicode printing related work on that).

The main thing that is difficult in a non-Unicode desktop is entering 
Unicode characters, but there are ways around that and for many 
applications being able to receive and render Unicode text would be a 
huge step forward already. The most obvious candidate in that respect 
is of course EasiWriter/TechWriter because Word files have Unicode 
content. However, that is a huge task and sadly only a small fraction 
of the user base is interested in non-Latin text.

-- 
Martin
---------------------------------------------------------------------
Martin Wuerthner         MW Software      http://www.mw-software.com/
        RISC OS Software for Design, Printing and Publishing
---------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#4999

In article <bf0d4d8352.martin@bach.planiverse.com>,
   Martin Wuerthner <spamtrap@mw-software.com> wrote:

> Instead of asking for an improved OS you need to ask for Unicode aware
> applications. Improving the Unicode support in the OS will not make any
> difference at all as long as applications are refusing to go Unicode.

All right, I can understand that. It even sounds encouraging, since half of
the work (the OS) seems to be done already.


> This is not a chicken-and-egg situation because the existing Unicode 
> support is good enough to display, process and print Unicode text 
> (PostScript printing requires the PostScript 3 driver - credits to 
> John Tytgat for doing all the Unicode printing related work on that).

Well, that sounds even better. But why can't I print the Unicode text that
is displayed by !Edit? Is that because !Edit only supports direct text
printing (or whatever it is called)?


> The main thing that is difficult in a non-Unicode desktop is entering 
> Unicode characters, but there are ways around that and for many 
> applications being able to receive and render Unicode text would be a 
> huge step forward already.

May I point at !KeyMap, a programmable keyboard driver that supports
Unicode, written by Richard Spencer and - cough - me. Receiving Unicode
should therefore no longer be a problem for an application (although
Chinese and other zillion+ character languages are still far beyond the
scope of KeyMap). But rendering? I would really love to see OvationPro, or
any text capable editor for that matter, rendering unicode fonts.


> The most obvious candidate in that respect is of course
> EasiWriter/TechWriter because Word files have Unicode content. However,
> that is a huge task and sadly only a small fraction of the user base is
> interested in non-Latin text.

Apologise for not immediately understanding, but what exactly is a huge
task? Displaying Unicode Word files, or displaying Unicode fonts tout
court?

!Dict can display and edit Unicode fonts. As a matter of fact, you helped
me enormously by explaining how caret positioning works. Of course, the
editor of !Dict is extremely limited and even then I managed to make the
process buggy, but if I can do it, then it can't be that difficult.
Or am I missing a lot of points again?

Kind regards,
Paul Sprangers

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.sys.acorn.misc

csiph-web