Life in Mirality
23 November 2017, 01:18:06 *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: MAX Codelist Manager v2.3 released!
 
   Home   Help Search Login Register  
Pages: [1]
  Print  
Author Topic: Fixed-Width Fonts in HTML/Pueblo Format  (Read 15283 times)
 
0 Members and 1 Guest are viewing this topic.
Snomad
Lurker
*

Offline Offline

Canada Canada

Posts: 1


View Profile
« on: 19 August 2008, 17:20:39 »

Most MUSH code is formatted to suit the old VT100, etc. fonts, which are fixed-width. The [columns()] function specifically supports fixed-width  fonts, as do other functions. I've tried everything in the helpfiles to force fixed-width fonts while still evaluating HTML sent by the world for Pueblo interpretation. Here are my results:

CODE STRING:
@pemit me=[columns(Columns Columns Columns Columns Columns Columns Columns Columns Columns Columns,15)]

MODE OUTPUT
No mode change/raw

Columns Columns Columns Columns Columns
Columns Columns Columns Columns Columns

<img xch_mode=text>
Columns Columns Columns Columns Columns Columns Columns Columns Columns Columns

<img xch_mode=html>
Columns Columns Columns Columns Columns
Columns Columns Columns Columns Columns

<img xch_mode=purehtml>
Columns Columns Columns Columns Columns Columns Columns Columns Columns Columns

<xch_mudtext>
Columns        Columns        Columns        Columns        Columns        <br.>Columns        Columns        Columns        Columns        Columns        <br.>GAME: Database being saved.<br.>

(Note: I had to put the periods in or the BRs got evaluated as carriage returns and didn't show in the post.)

The last one got me my fixed-width font and the spaces didn't truncate or become smaller, so the columns function actually printed nicely, but at the expense of all HTML being evaluated. What can I do to have fixed-width be the default, with a forced call if I want any other kind of font, and then going back to fixed-width, as the standard in MUSH? I'll meddle with the hardcode if I have to, but I have no clue or idea how to do this. HELP! MUCK does it seamlessly without problem. Why can't MUSH?

P.S. I didn't fix my mode back but simply typed QUIT and got this:

<body.><br.><center.><hr width="80%".><font size=+2.><b.>The world 'Blue Rose' has disconnected.</b.><br.><br.><a href="pueblo:disconnect" xch_hint="Close the world log window and return to the world list" target="_self".>Return to the world list</a.><br.><br.><a href="pueblo:reconnect" xch_hint="Clear the world log window and reconnect to this world" target="_self".>Reconnect to this world</a.><br.></font.><hr width="80%%".></center.><br.>

Again, periods have been placed so the code won't evaluate and instead will print in the post. Should we be able to break the World List page like that so easily? I have to shut down and restart Pueblo to recover. There's no way to get the World List back.


~Jakk
« Last Edit: 19 August 2008, 17:33:55 by Snomad » Logged
Miral
Administrator
*****


Offline Offline

New Zealand New Zealand

Posts: 61


View Profile WWW
« Reply #1 on: 20 August 2008, 00:17:37 »

Ok.  The rules for all this stuff are a little murky, and it's been a while (and I'm not sure I entirely worked out some of it to begin with).  But I did put a big section on some of this stuff in the new help system (also coming Real Soon Now™).

First of all, if you are in xch_mode=text or xch_mode=purehtml then newlines are left alone; if you are in xch_mode=html then each newline in the incoming stream is replaced with a <br> for rendering.  (The text mode also influences whether Pueblo itself will issue <xch_mudtext> blocks when it wants to insert random HTML of its own.  I'm not entirely convinced that the way it chooses to do this actually makes sense, but it's The Way It Has Always Been Done.)

There are basically a couple of different ways to HTMLise a world, AFAIK.  The first is minimalist -- leave the mode as text and keep everything within the initial <xch_mudtext> block, then wrap any usage of any other HTML tag with </xch_mudtext>(some HTML)<xch_mudtext>.  An important thing to remember when doing this is that the <xch_mudtext> tag does not need to be nested "properly" -- it's perfectly legal to do something like this:
abc </xch_mudtext><b><xch_mudtext>123</xch_mudtext></b><xch_mudtext> def
Similarly you can switch in and out of mudtext within anchor tags, or any other tags you like.

The second approach is completist -- issue a </xch_mudtext><img xch_mode="purehtml"> soon after connection, and from then on only emit HTML.  This means that you'll have to handle the line breaks and paragraphs yourself.  If you want to get monospaced text in this mode, then you can use the <tt> or <code> tags, just like in normal HTML.

(It's probably also worth mentioning that ANSI codes should only be used in the former scenario -- they might do something odd if you use them within HTML mode.)

I'm not entirely sure what the MUSH codebase does by default.  Maybe it's trying to be too helpful?

Regarding the last one, that's a little bit worrying; sounds like a bug.  So it was left in purehtml-with-mudtext mode when that happened?  I suspect that's the fault of the way it tracks which state it's in, which I mentioned in passing above.  Maybe I need to take a harder look at that.
« Last Edit: 20 August 2008, 00:25:49 by Miral » Logged
Masakikyoya
Lurker
*

Offline Offline

Albania Albania

Posts: 1


View Profile
« Reply #2 on: 29 June 2015, 22:45:00 »

It is something that must be applied to ourselves
Logged

Nmoghing
Lurker
*

Offline Offline

Azerbaijan Azerbaijan

Posts: 3


View Profile
« Reply #3 on: 21 January 2016, 23:45:59 »

I like to think and guidance to anyone whether anything.
Logged

Nmoghing
Lurker
*

Offline Offline

Azerbaijan Azerbaijan

Posts: 3


View Profile
« Reply #4 on: 21 January 2016, 23:48:05 »

I was very pleased to hear the views of all people.
Logged

Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.13 | SMF © 2006-2011, Simple Machines LLC Valid XHTML 1.0! Valid CSS!

Bad Behavior has blocked 38 access attempts in the last 7 days.