Top Mud Sites Forum - View Single Post

plamzi · 06-11-2014, 10:18 AM

When I was considering it, I went through the use cases you listed. It seems to me that a modern web client has a much easier way of handling these things for all games, rather than offering some kind of special treatment for the few games that use NAWS. For instance, the app has a split screen feature that lets you read long text at your own pace.

Likewise, offering the user a way to lift any fixed width (and using easy CSS for auto-wrapping) is a few lines long, and it will provide a more consistent handling across games than if I tried to calculate the current character width (for a user-resizable window with scalable font, mind you) and then told the server about it. Seems like a huge pain for the opposite of gain.

Doesn't have to be. I'll meet anyone in the middle and test together. The <IMAGE> tag is so close to HTML that I just added support for <image url=""> in one line. It won't take very long at all on my end to support it fully. Just let me know.

I'm actually not seeing a spec for setting a font name, so I'm not sure how ww_crimson is setting "Comic Sans MS" in another client. I hope he shares some details.

What I am seeing is the <TT> tag that is supposed to toggle "non-proportional font". If by that they mean "non-monospace" then, for the effect you are looking for, it seems like you would need to wrap most of your text in <TT> and then unset it for things that need to be displayed fixed-width? It seems like the inverse would be much less work.

Supporting <TT> will not be a problem, as I can just pick a good non-monospace font with extensive Unicode characters and allow the server to toggle in between. Are you requesting this feature and will you help me test it? (I know that you have your own custom client so not sure how much of a focus this would be for you.)

Also worth considering in this context of this discussion is that the Portal app supports HTML, so if no other client under the sun supports MXP <IMAGE> or <TT>, then you may want to tap into that for a wealth of display options, including showing actual tables, and setting any web font you can reasonably expect the user's browser to have, etc. If you want to do neat toggles instead of requesting the font again and again, just wrap it in a <STYLE> tag. There is even more flexibility available on the front end to extend functionality via the API.

06-11-2014, 10:18 AM	#28
plamzi Senior Member Join Date: Nov 2009 Home MUD: bedlam.mudportal.com:9000 Home MUD: www.mudportal.com Posts: 292	Re: www.mudportal.com When I was considering it, I went through the use cases you listed. It seems to me that a modern web client has a much easier way of handling these things for all games, rather than offering some kind of special treatment for the few games that use NAWS. For instance, the app has a split screen feature that lets you read long text at your own pace. Likewise, offering the user a way to lift any fixed width (and using easy CSS for auto-wrapping) is a few lines long, and it will provide a more consistent handling across games than if I tried to calculate the current character width (for a user-resizable window with scalable font, mind you) and then told the server about it. Seems like a huge pain for the opposite of gain. Doesn't have to be. I'll meet anyone in the middle and test together. The <IMAGE> tag is so close to HTML that I just added support for <image url=""> in one line. It won't take very long at all on my end to support it fully. Just let me know. I'm actually not seeing a spec for setting a font name, so I'm not sure how ww_crimson is setting "Comic Sans MS" in another client. I hope he shares some details. What I am seeing is the <TT> tag that is supposed to toggle "non-proportional font". If by that they mean "non-monospace" then, for the effect you are looking for, it seems like you would need to wrap most of your text in <TT> and then unset it for things that need to be displayed fixed-width? It seems like the inverse would be much less work. Supporting <TT> will not be a problem, as I can just pick a good non-monospace font with extensive Unicode characters and allow the server to toggle in between. Are you requesting this feature and will you help me test it? (I know that you have your own custom client so not sure how much of a focus this would be for you.) Also worth considering in this context of this discussion is that the Portal app supports HTML, so if no other client under the sun supports MXP <IMAGE> or <TT>, then you may want to tap into that for a wealth of display options, including showing actual tables, and setting any web font you can reasonably expect the user's browser to have, etc. If you want to do neat toggles instead of requesting the font again and again, just wrap it in a <STYLE> tag. There is even more flexibility available on the front end to extend functionality via the API.