editor non-monospace font interoperability suggestion

editor non-monospace font interoperability suggestion

Post by Kurt Bigle » Sat, 12 Jul 2003 11:11:56



I have always wished I could switch from using a monospace font to something
else, but to do so would wreak havoc on indenting.  Particularly I am
referring to indenting created by mid-line tabs.

In the past I have been in programming communities wherein some people did
use alternate fonts (e.g. Geneva) and this did cause a lot of hassle.

Meanwhile, it is such an easy problem to solve - except of course that maybe
MetroWerks is using someone else's editor code.

My suggestion is that text positions be computed for non-monospace fonts in
a way that is interoperable with monospace fonts, which eliminates damaged
column alignment, at least 99% of the time.

The way to do this is to compute the text position independently for each
block of text which follows one or more tabs anywhere on a line.  The trick
would be to simply compute the position AS IF it were for a monospace font.
This can be done by simply totalling the number of virtual monospace
characters on the line prior to the block of text in question, counting each
character as 1, and bumping forward to the next multiple of 4 each time a
tab is encountered in a forward scan.  Then take that number and multiply it
by the "M" width in the current font to compute the x pixel position.  Allow
the M width value to be specified as a customizable value, overriding the
actual M width in the current font.

This should allow communities of programmers to coexist peacefully in spite
of differing font preferences.

Thanks,
Kurt Bigler

 
 
 

editor non-monospace font interoperability suggestion

Post by MW Ro » Sun, 13 Jul 2003 00:41:16




Quote:>I have always wished I could switch from using a monospace font to something
>else, but to do so would wreak havoc on indenting.  Particularly I am
>referring to indenting created by mid-line tabs.

>In the past I have been in programming communities wherein some people did
>use alternate fonts (e.g. Geneva) and this did cause a lot of hassle.

>Meanwhile, it is such an easy problem to solve - except of course that maybe
>MetroWerks is using someone else's editor code.

>My suggestion is that text positions be computed for non-monospace fonts in
>a way that is interoperable with monospace fonts, which eliminates damaged
>column alignment, at least 99% of the time.

>The way to do this is to compute the text position independently for each
>block of text which follows one or more tabs anywhere on a line.  The trick
>would be to simply compute the position AS IF it were for a monospace font.
>This can be done by simply totalling the number of virtual monospace
>characters on the line prior to the block of text in question, counting each
>character as 1, and bumping forward to the next multiple of 4 each time a
>tab is encountered in a forward scan.  Then take that number and multiply it
>by the "M" width in the current font to compute the x pixel position.  Allow
>the M width value to be specified as a customizable value, overriding the
>actual M width in the current font.

>This should allow communities of programmers to coexist peacefully in spite
>of differing font preferences.

I'm not sure this would work as effectively as you think, but I'll pass
it on.  Do you know of any other editors that can currently do this?

Ron

--
           Metrowerks has moved, our new address is now
                     7700 West Parmer Lane
                       Austin, TX 78729
        Sales and Support 512-996-5300   800-377-5416    


 
 
 

editor non-monospace font interoperability suggestion

Post by David Dunha » Sun, 13 Jul 2003 11:05:12




> I'm not sure this would work as effectively as you think, but I'll pass
> it on.  Do you know of any other editors that can currently do this?

I think Project Builder may try.

As you know, both it and Symantec C++ support syntax styling, and doing
that right pretty much requires using tabs from the monospaced font
(even if you've got a comment in a proportional font).

--

http://www.pensee.com/dunham/
    "I say we should listen to the customers and give them what they want."
    "What they want is better products for free." --Scott Adams

 
 
 

editor non-monospace font interoperability suggestion

Post by Kurt Bigle » Mon, 21 Jul 2003 09:20:24






>> I have always wished I could switch from using a monospace font to something
>> else, but to do so would wreak havoc on indenting.  Particularly I am
>> referring to indenting created by mid-line tabs.

>> In the past I have been in programming communities wherein some people did
>> use alternate fonts (e.g. Geneva) and this did cause a lot of hassle.

>> Meanwhile, it is such an easy problem to solve - except of course that maybe
>> MetroWerks is using someone else's editor code.

>> My suggestion is that text positions be computed for non-monospace fonts in
>> a way that is interoperable with monospace fonts, which eliminates damaged
>> column alignment, at least 99% of the time.

>> The way to do this is to compute the text position independently for each
>> block of text which follows one or more tabs anywhere on a line.  The trick
>> would be to simply compute the position AS IF it were for a monospace font.
>> This can be done by simply totalling the number of virtual monospace
>> characters on the line prior to the block of text in question, counting each
>> character as 1, and bumping forward to the next multiple of 4 each time a
>> tab is encountered in a forward scan.  Then take that number and multiply it
>> by the "M" width in the current font to compute the x pixel position.  Allow
>> the M width value to be specified as a customizable value, overriding the
>> actual M width in the current font.

>> This should allow communities of programmers to coexist peacefully in spite
>> of differing font preferences.

> I'm not sure this would work as effectively as you think, but I'll pass
> it on.

I think the effectivness of it will be statistical, and the optimum
effectiveness would be determined by the choice of "monospace character
width" for the given non-monospace font.  I suggested using the "m" width,
but this is probably wrong.  You really want the width of the average
chracter based on typical usage, which of course a slippery concept, but I
think a good average will work well.  A little bit of playing around might
reveal a good simple rule such as a particularly weighted average of the "n"
width and the "m" width.  Perhaps it is this weight (e.g. 40% meaning 40% of
the way from "n" to "m") which would be the most useful control to offer in
the user-interface.

Basically you want to achieve interoperability both in going from monospace
to non-monospace and from non-monospace to monospace.  If I am thinking
correctly, the two directions form a trade-off.  If you chose a relatively
wide "monospace character width" in your non-monospace font, you will
increase the chances that a previously monospace document will come in
without a conflict.  But then if you type a bit in non-monospace land and
put too many of those nice narrow characters BEFORE another tab, then going
back to monospace land will have problems, because those narrow characters
become wide and can no longer be placed prior to that next desired tab
position based on the metrics used in non-monospace land.  Conversely if you
make the "monospace character width" too narrow, then problems occur when
importing from monospace land.

Allowing the "monospace character width" to be customizable in some fashion
will allow a given site to optimize based on their expected path.  For
example a whole company may be making a transition from monospace to
nonmonospace and may not care so much about going the other direction, in
which case the "monospace character width" can be set wider to optimize that
direction of migration.  Of course problems can still occur when going from
one non-monospace font to another, and the same issues apply in terms of
chosing the "monospace character width" (or whatever it should really be
called) effectively for both (or all of) the fonts involved.

In any case my suggestion would be that tabs remain explicit entities in the
document, so that the problems that arise will involve rendering only, not
representation.

Quote:> Do you know of any other editors that can currently do this?

I am not aware of any, but I use neither project builder nor Symantec C++
(does this still exist?) so I can not expand on David Dunham's comments
regarding these.

-Kurt

- Show quoted text -

Quote:

> Ron

 
 
 

editor non-monospace font interoperability suggestion

Post by David Dunha » Tue, 22 Jul 2003 12:56:10




> > Do you know of any other editors that can currently do this?

> I am not aware of any, but I use neither project builder nor Symantec C++
> (does this still exist?) so I can not expand on David Dunham's comments
> regarding these.

I wouldn't say that Symantec C++ still exists, but when it did, it did
syntax styling (which Metrowerks still can't). I don't recall any
serious problems mixing monospaced program text and proportional
comments on the same line, with tabs.

Project Builder has syntax styling too, but I haven't used it enough to
know how good a job it does with mixing and tabs (I think it's fairly
good).

--

http://www.pensee.com/dunham/
    "I say we should listen to the customers and give them what they want."
    "What they want is better products for free." --Scott Adams

 
 
 

1. PDF with non-subsetted fonts -> PDF with subsetted fonts

What is the fastest way to convert a PDF with non-subsetted fonts to a
PDF with subsetted fonts.  What I am currently doing is:

.pdf w non subsetted fonts ==> .ps w. fonts (produced by xpdf)
.ps ==> .pdf w. subsetted fonts (produced by GS using fonts in a
resource folder)

Is there a better way to do this?  If third-party software is needed
is it free? robust?

Thanks,
Steve

2. monkey mode?

3. Suggestion for an editor similar to the Borland C editor?

4. Cold Hard Cache

5. WANTED: font editor or alternate fonts for wyse 60/150's

6. Help with Ventel 2400

7. Interoperability problem: VisiBroker (Java applet) Client <-> non-VisiBroker Server

8. X10, CEBus, etc.

9. none of the suggestions worked, was Re: Reading CDROMs with non-standard format on a PC

10. Need suggestions for FONT CD for Business Card Typesetting.

11. Seeking text editor suggestion

12. Looking for a good editor need suggestions