Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are
spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the
password reset link.
Due to spam on this forum, all posts now need moderator approval.
Entire forum
➜ MUSHclient
➜ Bug reports
➜ MXP and font tags
It is now over 60 days since the last post. This thread is closed.
Refresh page
| Posted by
| Shadowfyr
USA (1,792 posts) Bio
|
| Date
| Sat 06 Oct 2001 11:21 PM (UTC) |
| Message
| Not sure if this is a mushclient thing or somethig the mud is doing.
I am using mushclient to access agesofdespair.org:5000
While this is a ansi only mud, I decided to see what would happen if I tried sending myself a 'tell' with MXP font information encoded in it. Sort of worked, but not the way it should have.
The problem seems to be that Mushclient uses the solid black character (not sure 179 or something). to fill in to the end of the line. Or I assume it does, since everything after </font> is a solid block in the selected font color, inctead of the previous color. Placing a single character after the tag stops this from happening.
There was also a problem with using more than one tag, but it seems to be caused by the muds insistance of auto-wrapping tells and channels, though not anything else. | | Top |
|
| Posted by
| Nick Gammon
Australia (23,173 posts) Bio
Forum Administrator |
| Date
| Reply #1 on Sun 07 Oct 2001 12:15 AM (UTC) |
| Message
| Go to File -> Global Preferences -> General
Check that "Bleed background colour to edge" is unchecked.
If so, let us know. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Shadowfyr
USA (1,792 posts) Bio
|
| Date
| Reply #2 on Mon 08 Oct 2001 09:25 PM (UTC) |
| Message
| Hmm. Yeah that was turned on. Though it is strange that what should have been a foreground color becomes a background color at the end of the line. I had to resort to using <color black> and a single invisible character to fix it. Changing that setting does fix it though, thanks.
However, despite the fact that I am turning MXP/Pueblo on, I can't seem to get any <B>, <I>, etc. commands to work. I am using the Terminal font, but other fonts don't seem to change according to the commands I send either. Though they are parsed. Unfortunately since the mud I play does not actually support MXP and strips out the escape character to prevent using ansi, I can't test it with anyone else. Almost everyone else is using zmud. :p I am instead using 'tell {my own name}' and 'say' to experiment, but only the color command seems to work.
I also noticed reading another post that you have no plans to support inline graphics or font changes.... Well the first of the two may detract from the mud if abused (but then so does a lot of colors that serve no practical purpose). The second of the two could be wery useful for a mud designer (again if used properly). Had I a machine I could use to run one I would almost certainly end up using that feature, making it's absence in one of the two best clients that currently exist a major pain. | | Top |
|
| Posted by
| Nick Gammon
Australia (23,173 posts) Bio
Forum Administrator |
| Date
| Reply #3 on Mon 08 Oct 2001 09:43 PM (UTC) |
| Message
| Check that in Configuration -> Appearance -> Output that "Show bold" and "Show italic" are checked.
The problem with font changes is that, unless all fonts have the same vertical size (ie. point size, effectively) then it makes calculations much harder (and therefore slower) when it comes to working out which point on the screen is which line in the output buffer.
It would, I suppose, be relatively easy to allow different fonts providing they all were the same vertical height.
However nowadays by using MXP commands you can have all sorts of colour changes (not just the 16 ANSI colours) that you can make different blocks of text look different by using different combinations of colours (eg. text on a light grey background).
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Shadowfyr
USA (1,792 posts) Bio
|
| Date
| Reply #4 on Tue 09 Oct 2001 08:34 PM (UTC) |
| Message
| Dumby me, didn't read those settings close enough. lol
Yeah. I can see where different height fonts are a problem. I have nightmares just trying to figure out how justification works when the code describing how to figure the length of a line, using non-fixed width fonts seems to give you an average or something, instead of an actually width. :p It is a scary concept. Dealing with heights ,while disturbing, has got to be easier. Most programs handle the different height fonts by making the line equal to the space occupied by the largest font on it. All programs like Word, Wordpad, Cryptedit, etc. work this way. And since no commands currently exist for positioning the text (save ansi commands, which are line based anyway), there is no reason that they can't be treated the same way. Will it be slower? Maybe...
As to using other colors... I went to a mud called Coolmud a few days ago, since it advertised using MXP. Every other word was a different color on some pages. I never even left the newbie section it was so horrid. Sometimes mearly changing the font face is a better way to emphasize something that coloring it in a way that jumps off the screen screaming at you. ;) Of course even ansi colors can be over used, so... | | Top |
|
| Posted by
| Nick Gammon
Australia (23,173 posts) Bio
Forum Administrator |
| Date
| Reply #5 on Tue 09 Oct 2001 09:45 PM (UTC) Amended on Tue 09 Oct 2001 09:46 PM (UTC) by Nick Gammon
|
| Message
| The horizontal calculation is bad enough - since each character can be a different width, working from a cursor position back to a character number is tedious (eg. when you click and drag to make a selection). Basically I have to work out the "progressive width" of the line by adding the width of each character until I reach where the mouse is pointing. However there is normally only a maximum of 80 characters to process, or thereabouts.
However you can potentially have 500,000 lines of text in the output buffer, and if you move the scroll bar "thumb" to the 50% point, then to work out which line of the 500,000 is half-way through, I would need to add up 250,000 line heights, which could potentially take a lot longer.
And, scrolling is something I tend to do a fair bit myself.
Finally you have the issue - that strikes some web pages and word processor documents - that if you let the MUD specify fonts, you have the issue of what to do if the font isn't installed on the player's PC. The MUD designer might incorporate a whole lot of nice script fonts, for instance, but if the player doesn't have that font, the substituted font might look a lot worse, and destroy the effect.
At least with a single font, you presume the player won't choose a font s/he doesn't have on their PC. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Shadowfyr
USA (1,792 posts) Bio
|
| Date
| Reply #6 on Wed 10 Oct 2001 05:42 AM (UTC) |
| Message
| >However you can potentially have 500,000 lines of text in
>the output buffer, and if you move the scroll bar "thumb"
>to the 50% point, then to work out which line of the
>500,000 is half-way through, I would need to add up 250,000
>line heights, which could potentially take a lot longer.
Umm. Why?? 50% of 500,000 lines is 250,000 lines, the height is only important when you display it. There is not much point in worrying about how big the lines are unless you are storing the actual image, which would be a major waste of memory for something like this. If it turns out not to be exactly 50% of the image, then it will still be very close to it. Short of using 500 lines of 24 point fonts then switching to 10 point, the difference would tend to average out over the entire buffer. Besides, how do you get 'exactly' 50% on a scroll bar anyway? ;)
As to the font issue... Agreed. It is bad enough that only two good fonts exist (that are free at least) that are fixed width and that lets ascii art display correctly. Still, there is nothing to prevent it from using the normal 'get that closest font' feature. Or preventing the muds from supplying any extra fonts needed, the same way they sometimes provide links to clients or downloadable newbie docs on their web pages. Also, being able to force the font into Terminal or Fixedsys, in order to correctly display stuff, lets the user decide what font they like best, without forcing them to abandon it because of the muds ascii art.
Put simply, it is up to the designers of the mud to make sure that the right fonts are available, not the user. Same with anything else they use to enhance the mud. If they are not smart enough to plan ahead, their mud probably won't be worth visiting anyway. | | Top |
|
| Posted by
| Nick Gammon
Australia (23,173 posts) Bio
Forum Administrator |
| Date
| Reply #7 on Thu 11 Oct 2001 10:46 PM (UTC) |
| Message
| Yes you are right. Line 250,000 could be considered halfway through 500,000 lines, at least as a line count goes, rather than a pixel count, which would probably average out over a large range.
However you still have the problem of a mouse clicking on a particular screen, if the lines are all different heights, to work out which line the click is in.
Anyway, I'll keep it in mind for a future version. :) |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).
To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.
20,937 views.
It is now over 60 days since the last post. This thread is closed.
Refresh page
![[Go to top]](/images/gototop.gif)
top