 sj |
||
|
||
Mudcat rewriting preformatted text
|
|
|
Subject: RE: Mudcat rewriting preformatted text From: JohnInKansas Date: 15 May 11 - 04:59 AM Good idea Gargoyle, but the code has <br> breaks in it that I don't think you want in the ABC. As pointed out in the first post, the line breaks (<br>) inserted inside a <pre> with Automatic Line Breaks turned on result in a "leading space" on each line that is not "correct html." This is a problem, especially for posts of ABC text files. So far as has been seen, the same error does NOT occur elsewhere in posts here. Changing the way mudcat does it is something Max will have to do, but as some appear not to have understood my suggestions about what might be done until it's fixed, I'll describe how I believe the problem might be handled until a fix is in place. Read this only if interested, and use whatever other methods work better for you. The ABC bit posted by Jack at 13 May 11 – 05:19 PM shows line breaks (<br>) in the page code appropriate to break the lines as they are displayed in the post. The source code looks like: <pre>X:1<br>T:Gleanntain Ghlas Ghaoth Dobhair<br>B:Eamonn Jordan, Whistle and Sing<br>M:3/4<br>L:1/4<br>K:DMix<br>D |A> B c|A2 D |A2 A|A F D |C B, C|D2 D|D3-|D2<br>A/B/|c A G|A2 B/c/|d2 c|A2 d/d/|c B A|G D E|C3-|C2<br>c/c/|c A G|A B c |d2 c|A2 d |c B A|G D E|C3-|C2<br>D/D/|A B c|A2 D |A F A|G F D |C B, C|D2 D|D3-|D2|] </pre> <P> <p> Works, but boy is it an ugly and timeconsuming solution. <P> (The probably obsolete "guide to ABC" that I have handy indicates that "the song is ended by a blank line" and if that's the case there probably should be an additional <br> immediately ahead of the </pre>, but current ABC programs may not need it(?)) When I copy the ABC posted by Jack at 13 May 11 - 05:19 PM and paste it into Notpad there are no line breaks of any kind on the Notepad copy. This is confirmed by viewing the the file in HEX notation. The Notepad file looks like: X:1T:Gleanntain Ghlas Ghaoth DobhairB:Eamonn Jordan, Whistle and SingM:3/4L:1/4K:DMixD |A> B c|A2 D |A2 A|A F D |C B, C|D2 D|D3-|D2A/B/|c A G|A2 B/c/|d2 c|A2 d/d/|c B A|G D E|C3-|C2c/c/|c A G|A B c |d2 c|A2 d |c B A|G D E|C3-|C2D/D/|A B c|A2 D |A F A|G F D |C B, C|D2 D|D3-|D2|] When I copy from the post and Paste into Word, it looks like: X:1** T:Gleanntain Ghlas Ghaoth Dobhair** B:Eamonn Jordan, Whistle and Sing** M:3/4** L:1/4** K:DMix** D |A> B c|A2 D |A2 A|A F D |C B, C|D2 D|D3-|D2** A/B/|c A G|A2 B/c/|d2 c|A2 d/d/|c B A|G D E|C3-|C2** c/c/|c A G|A B c |d2 c|A2 d |c B A|G D E|C3-|C2** D/D/|A B c|A2 D |A F A|G F D |C B, C|D2 D|D3-|D2|] ¶ In Word, the "break" glyph that is seen at the end of each line is similar to the "Return Arrow" found on the Enter Key of many keyboards, but I don't find that "picture" anywhere in usable Unicode or ASCII/ANSI character sets, so for purposes of illustration I've replaced it with the arbitrarily chosen "**" In a text editor, things copied from an html page may either ignore (not display) any "break symbol," and although there may be a CR LF (Hex OD OA) in the file it's not generally visible. The text editor alternatively may simply drop them (leave them out of the file), as apparently happened with my paste into Notepad. In Word, there is always a visible break symbol if you choose to have it displayed, and the one most commonly seen when pasting from html has the decimal character number value 0011. In ancient ASCII the Char 0011 (Hex 0B) was sometimes "named" as a paragraph break combining a CR and a LF, although most modern charts name it as a "vertical tab." So far as I've seen, a <br> in html code will always display as this character when pasted into Word. (I occasionally see HTML pages where the same "return" arrow displays for a different break with Decimal character value 031 (Hex 1F) but I haven't bothered to find what HTML code produces this one since it seems to be uncommon.) A paragraph break, <p> copies into Word as a normal paragraph break, and in Word is displayed as a Pilcrow glyph. When copying from the web to save notes (and for potential posting) I generally paste into Word, and in most cases replace the "<br> breaks (decimal 0011 or 0031) with paragraph breaks. With the automatic line breaks, as they work everywhere except inside the <pre> tags editing and posting is simplified by having all one kind of break in the document. In the Edit|Find and Edit|Replace utility in Word, a paragraph break is entered as ^p. Any character can be entered by its Decimal character number using ^nnnn, where nnnn is the number. The preferred method is to use 4 places, with leading zeros, although it usually works with just the "significant digits." You can also Find and/or Replace characters using their Unicode char numbers using the form ^Unnnn. Using Find ^011 and Replace With ^p converts all of the <br> "soft breaks" to paragraph breaks ¶ If you set up the ABC text you want to display in Word, using "Enter" to insert line breaks as paragraphs, when you get it as pretty as you want, you can Find ^p and Replace With <br>, hit Replace All, and you should have exactly the form shown in the page code for the post Jack made. Using this method you do not have to type <br> at the end of each line, as you'd have to do in a simpler text editor. From the Post as it pastes into Word: X:1** T:Gleanntain Ghlas Ghaoth Dobhair** B:Eamonn Jordan, Whistle and Sing** M:3/4** L:1/4** K:DMix** D |A> B c|A2 D |A2 A|A F D |C B, C|D2 D|D3-|D2** A/B/|c A G|A2 B/c/|d2 c|A2 d/d/|c B A|G D E|C3-|C2** c/c/|c A G|A B c |d2 c|A2 d |c B A|G D E|C3-|C2** D/D/|A B c|A2 D |A F A|G F D |C B, C|D2 D|D3-|D2|] ¶ Find ^0011 and Replace with ^p Gets rid of the mixed break forms and makes it look like: X:1¶ T:Gleanntain Ghlas Ghaoth Dobhair¶ B:Eamonn Jordan, Whistle and Sing¶ M:3/4¶ L:1/4¶ K:DMix¶ D |A> B c|A2 D |A2 A|A F D |C B, C|D2 D|D3-|D2¶ A/B/|c A G|A2 B/c/|d2 c|A2 d/d/|c B A|G D E|C3-|C2¶ c/c/|c A G|A B c |d2 c|A2 d |c B A|G D E|C3-|C2¶ D/D/|A B c|A2 D |A F A|G F D |C B, C|D2 D|D3-|D2|] ¶ In the case where what you copy from a post and paste into Word has the extraneous leading spaces, you can Find "^p " (A paragraph break followed by a space) and Replace With "^p" (A paragraph break not followed by a space) and click Replace All to clean it up. In most text editors you can't easily do "global replacements" and would need to take out the offending spaces one at a time. Replacing ¶ (typed as ^p in the Find Box) with <br> converts it to "coded html" for posting as, clicking Replace All gets: X:1<br>T:Gleanntain Ghlas Ghaoth Dobhair<br>B:Eamonn Jordan, Whistle and Sing<br>M:3/4<br>L:1/4<br>K:DMix<br>D |A> B c|A2 D |A2 A|A F D |C B, C|D2 D|D3-|D2<br>A/B/|c A G|A2 B/c/|d2 c|A2 d/d/|c B A|G D E|C3-|C2<br>c/c/|c A G|A B c |d2 c|A2 d |c B A|G D E|C3-|C2<br>D/D/|A B c|A2 D |A F A|G F D |C B, C|D2 D|D3-|D2|] <br> Just like what Jack posted. Past experience has been that you can also copy the ABC (with the paragraph breaks) from Word and paste it into a text editor like Notepad, into the ABC program, or just Save As "Plain Text .txt" directly from Word, and the file should work in ABC. Having the "Replace All" function available to get rid of the offending leading spaces on each line, and being able to "one step replace" the line breaks with <br> for posting (until the <pre> breaks are fixed) makes it, IMO, worth passing through Word to whatever text editor or text program you need to get your final result. Unfortunately I've misplaced my VBRUN file so I'll have to dig one up before I can get my old ABC program running again to test what works and what doesn't. It's on a disk somewhere around the house. John |
|
Subject: RE: Mudcat rewriting preformatted text From: GUEST,.gargoyle Date: 14 May 11 - 09:08 PM View - Page Source Cut and paste desired section into notepad?
Sincerely, a simple P is much easier than these newly requested double BR - BR's |
|
Subject: RE: Mudcat rewriting preformatted text From: GUEST,Jon Date: 14 May 11 - 07:18 AM No John, ideally, this problem would be fixed at Mudcat. |
|
Subject: RE: Mudcat rewriting preformatted text From: JohnInKansas Date: 14 May 11 - 07:13 AM Jack - Word is a perfectly acceptable text editor that does everything that Notepad does, but with significantly more useful editing capability. As long as you "Save As .txt" a file edited in Word is indistinguishable from one edited in Notepad or any other text editor. It makes NO DIFFERENCE what program you use to copy the ABC code from the post and save it to your own computer, as long as the format of the file is plain text. I did assume that it would be known by all that ABC accepts only "plain text" code; but the subject under discussion was what the mudcat interpreter was doing to the post, not a tutorial on using ABC. John |
|
Subject: RE: Mudcat rewriting preformatted text From: GUEST,Jon Date: 14 May 11 - 07:00 AM will find there are line breaks within the pre. brs within the pre |
|
Subject: RE: Mudcat rewriting preformatted text From: GUEST,Jon Date: 14 May 11 - 06:38 AM Yes, Jack pre should break with the CR/LF it was supplied with but outside the pre won't. If writing a routine to handle the post's contents, the simplest way to handle this is probably to use a global search/replace function and change all CR/LF pairs to br. My leave pre alone version would have to scan through the post, to see whether in a pre or not and act or (otherwise) on the CR/LFs encountered accordingly. Personally and talking about elsewhere. as I don't think this substitution does cause a problem, I use the simple method. Re. Not believing it is a problem, if you step back a few posts and look at the source for the post where you seem happy with Gleanntain Ghlas Ghaoth Dobhair, you will find there are line breaks within the pre. You have just eliminated the leading spaces. |
|
Subject: RE: Mudcat rewriting preformatted text From: Jack Campin Date: 14 May 11 - 05:00 AM That means that the "Automatic Linebreak" function has to recognize either form and substitute for either one of them, and the "reader" on each user's browser has to change to whichever is appropriate for the machine it's on. No. Browsers recognize different character encodings - they can identify a linebreak in the context of a "pre" tag without it being labelled by "br". As I said, my own song lyric files do that, and nobody has a problem with them, even though (like Mudcat) I don't explicitly declare the character encoding I'm using and leave the browser to guess (naughty, naughty). John, you're way off base. ABC processors don't work the way you think they do, and hardly any ABC users would ever consider using Word with ABC. I've been using ABC for about 15 years, have had versions of Word all that time, and I don't think I've ever opened an ABC file with it. |
|
Subject: RE: Mudcat rewriting preformatted text From: JohnInKansas Date: 14 May 11 - 12:07 AM I'll agree, Jon, that it's probably best to clean up the ABC code before opening it in ABC. I get so many similar bits of trash with almost everything downloaded or copied from the web (and not just at mudcat) that it's just automatic to proof and clean before trying to do anything with it. The cleanup is trivially simple in Word, if you learned how to drive Word before Microsoft trashed it; but I'd hate to have to learn how starting from scratch in the new versions. I would expect that anything claiming to be a word processor should have similar capabilities. You can make the post (in <pre>) look right in the post just by putting a ¶ after the <pre> before the first line of the code. The copy/paste of the code (into Word) will have a leading space on each line, and you probably will want to remove them all to be assured that the ABC program won't burp on them. John |
|
Subject: RE: Mudcat rewriting preformatted text From: GUEST,Jon Date: 13 May 11 - 09:04 PM Re abc John, it says any line beginning with a letter in the range 'A-Z' or 'a-z' and immediately followed by a colon (:) is to be interpreted as a field. I think a leading space would break that one as it would "extended information fields", ie. lines starting with %%. In practice, some abc software will handle it (some producing warnings and others silently) and others will fail. In other words, it's "unpredictable"... |
|
Subject: RE: Mudcat rewriting preformatted text From: JohnInKansas Date: 13 May 11 - 08:46 PM With automatic linebreaks turned on, you could probably make the ABC post "look right" on mudcat by putting a paragraph break between the <pre> tag and the first line of the ABC. This would put an extra space at the start of each line: <pre> A line of stuff Another line</pre> Should display
When someone copies the ABC and pastes it elsewhere, there likely will be an extraneous space at the beginning of each line. I don't know whether that space would affect the ABC program; but if it does, in Word you can replace "^p " (a paragraph break followed by a space) with "^p" (a paragraphs break without a space after it) and "replace all" to remove all "leading spaces" at the beginning of all lines, before saving as text. The paste into Word may show a "soft break" in place of a paragraph break, in which case you'd replace "^011 " with either "^011" or "^p". The replace with ^011 will give you "soft breaks" and the ^p will give you normal paragraph breaks in the Word document. Either will save as "paragraph breaks" when you save from Word as "plain text" in a .txt file and reopen in Notepad, so it makes no difference which you use. John |
|
Subject: RE: Mudcat rewriting preformatted text From: GUEST,Jon Date: 13 May 11 - 08:32 PM Yes John but I think the CR/LF for line breaks holds throughout HTML. And yes, it is true that all of CR. LF, and CR/LF are used and different Operating Systems use different markers. I just don't think it applies in this instance. |
|
Subject: RE: Mudcat rewriting preformatted text From: JohnInKansas Date: 13 May 11 - 08:26 PM The details are a bit fuzzy since I haven't had my obsolete HTML book out recently, but I believe the "escape" form cited above applies only to URLS, and there's a different description for "body text" in posts. The escapes used for web addresses are a carryover from another standard (maybe it's the RFC1738?), included in the HTML std for reference. Web addresses use a different "language" than html posts. Within a post, the space (ASCII decimal 32, Hex 20) is a "printable" character, and no substitution/escape is necessary. The "control characters, like CR (decimal 13, Hex 0D) and LF (decimal 10, Hex 0A) appear to be "nonfunctional" if included in a post, regardless of how you code them. The "tag" <BR> is the only thing that works in the page code. It actually is somewhat difficult to find (on the web) an ASCII/ANSI Character chart that shows the "unprintable" characters. I did find one at ASCII Table on about the third or fourth page of a Google search return. I don't recall which was what, but back when we all used DOS, IBM's "paragraph" break was CR LF and Microsoft's was LF CR, or maybe it was the other way 'round. (Microsoft said it's a "special character" but has never defined a "code value" for it.) Since Windows and Macs also differ as to little endian and big endian, there probably is also a difference there as well. That means that the "Automatic Linebreak" function has to recognize either form and substitute <br> for either one of them, and the "reader" on each user's browser has to change <br> to whichever is appropriate for the machine it's on. The "extra" space could come from the interpretation by mudcat when it saves the post into the database, or could happen when the browser "reads" the post back from the code. John |
|
Subject: RE: Mudcat rewriting preformatted text From: GUEST,Jon Date: 13 May 11 - 05:46 PM Microsoft and some other "standards" differ in whether a "paragraph" break is a CR LF or a LF CR. Either a CR LF CR LF or a LF CR LF CR will always contain at least one "correct" pair, and the others will be "mostly ignored," or in some cases will contain two correct pairs in which case both will work. I think this time it is the HTML spec. Here is part of 4.01 section 17.13.4 "Form content types", application/x-www-form-urlencoded |
|
Subject: RE: Mudcat rewriting preformatted text From: JohnInKansas Date: 13 May 11 - 05:23 PM It occurs to me that some may be confused about how to do "the rest of the story" with Automatic Linebreaks turned off. From the time before we had automatic linebreaks, it was observed that if you use two consecutive paragraph breaks you'll always get the effect of a <br>, although some people will see one break and others will see two (ie a space between paragraphs). Microsoft and some other "standards" differ in whether a "paragraph" break is a CR LF or a LF CR. Either a CR LF CR LF or a LF CR LF CR will always contain at least one "correct" pair, and the others will be "mostly ignored," or in some cases will contain two correct pairs in which case both will work. If you turn off automatic line breaks you can type the rest of your post (outside the <pre> part) by just using Enter Enter for the other breaks in the rest of the message, or do the "formal" thing and put in <br> code for each break. John |
|
Subject: RE: Mudcat rewriting preformatted text From: Jack Campin Date: 13 May 11 - 05:19 PM Okay, let's try that.
X:1
Works, but boy is it an ugly and timeconsuming solution. |
|
Subject: RE: Mudcat rewriting preformatted text From: GUEST,Jon Date: 13 May 11 - 05:14 PM Fwiw John, I'd take a wild guess that a space has crept into a "global search/replace so instead of sort of replace("CR/LF", "br") which I don't think would cause a problem it's doing replace("CR/LF", "br ") |
|
Subject: RE: Mudcat rewriting preformatted text From: JohnInKansas Date: 13 May 11 - 05:08 PM In my preview, it appears that you can get the result wanted by: 1. Turn OFF Automatic Linebreaks. 2. Us <br> for all linebreaks between the <pre> and <\pre> tags. The easy way to use all <br> tags, if you have Word, is to just type the text in Word, highlight everything you want changed, and use Edit|Replace with ^p in the "replace" box and <br> in the "replace with" box, replace all. The ^p is how you tell Word Find/Replace to look for paragrah breaks (which shows as the Pilcrow symbol ¶ in Word, if you turn on "show all"). The <br> is just typed - not coded. I'll wait for somebody to try this, before studying the situation further. John |
|
Subject: RE: Mudcat rewriting preformatted text From: GUEST,Jon Date: 13 May 11 - 05:04 PM I don't know ColdFusion Jack so there could be built in features to handle an the contents of the HTML textarea or you might have to write a routine yourself. Either way, the post as received needs translation at some point(s). The breaks from the textarea are sent CR/LF pairs and outside of the pre, they need to be translated to "brs" or handled as paragraphs (p tag) for the post to be displayed properly. |
|
Subject: RE: Mudcat rewriting preformatted text From: JohnInKansas Date: 13 May 11 - 04:45 PM My previous post was an accident. I aimed at the preview box to click it, and missed and got submit instead. It appears that the extra space is added on all lines except the first one, so the appearance that everything is aligned correctly is obtained by using <pre>[space] at the beginning so that the first line aligns with the following ones. Unfortunately, when you copy from the mudcat page, the first space is dropped, so what you paste elsewhere has the first line "outdented" by one space - in your copy instead of in the post. The mudcat interpreter also changes paragraph brakes to "soft breaks" (decimal char 011), and uses a normal paragraph break only at the end of a <pre> post. In the page code, my "mistake" posted as: <pre> What is the problem<br> With pre format<br> When posting to<br> mudcat?</pre> <P> The program probably arises from the old html vagary about the <br>. The ASCII/ANSI standard originally defined a linefeed, which moved down one line, but continued at the current cursor place in the line. A "carriage return" was provided as a separate character to return to the start of the line, but a "cr" remained on the same line. In order to go to the start of the line and move down to a new line, it was necessary to have a "cr"+"lf" both. Unfortunately, some operating systems implemented a break (<br>) as cr+lf, and others implemented it as lf+cr. This difference is in the Operating Systems, and is not really an html thing. In order to make the <br> code work in ALL operating systems, at least for the older html interpreters it gets translated to what looks like either "lf cr lf" or "cr lf cr." HTML is, by early definitions, supposed to "ignore" any code it can't read, so the <br> always contains a "lf cr" and a "cr lf" in the <br> br, and the "extra" char – "either a lf or a cr" is "ignored," but in this case apparently appears as an extraneous "space." This same "effect" is NOT EXCLUSIVE TO MUDCAT but appears widely on the web. The "evidence" you'll see is that at many websites, anything you copy and paste has nearly all of the "paragraph breaks" typed by the person posting replaced with "soft breaks" that appear as a "broken arrow" in Word – if you are set to display everything. Word shows the same symbol, but for some pastes it appears as a decimal 031 character and in pastes from other pages as a decimal 011 character. This "other version" of our <pre> anomaly is found in .htm pages as well as in .cfm pages like mudcat. John |
|
Subject: RE: Mudcat rewriting preformatted text From: Jack Campin Date: 13 May 11 - 04:33 PM our filenames are *.cfm - they're all generated by a very old version ColdFusion, which creates Web pages "on the fly" from a database of messages. I figured it did something like that, but presumably CF doesn't edit the content of messages when putting a thread together - the "br" tags and the space will be added by whatever takes the user's input in the box and makes a database entry out of it. That should be a bunch of filtering scripts to stop users sabotaging everything by a simple mistake, and I'd be surprised if the scripts weren't human-readable and editable. I'll draw Max's attention to this if he doesn't see it first. |
|
Subject: RE: Mudcat rewriting preformatted text From: Jeri Date: 13 May 11 - 04:16 PM ...as in one continuous line, because the visual line breaks (not the auto ones or the br ones) are what show up as spaces. |
|
Subject: RE: Mudcat rewriting preformatted text From: Jeri Date: 13 May 11 - 04:14 PM Joe, if you use "Automatic linebreaks" then they're inserted, even in pre-formatted text. It wasn't always thus, so I believe some changes can be made to what the queries in ColdFusion display. I have an idea.
X:52 This was done by un-clicking automatic linebreaks and inserting them myself. It was also done with the text displaying without wrapping when I submitted it. |
|
Subject: RE: Mudcat rewriting preformatted text From: JohnInKansas Date: 13 May 11 - 03:59 PM What is the problem |
|
Subject: RE: Mudcat rewriting preformatted text From: Joe Offer Date: 13 May 11 - 03:45 PM Hi, Jack- if you look in the address bar of your browser, you'll see that our filenames are *.cfm - they're all generated by a very old version ColdFusion, which creates Web pages "on the fly" from a database of messages. The Forum is built on the forum that came with that Cold Fusion package. It used to be that you could find many forums on the internet that looked very much like Mudcat, but it's hard to find them nowadays because most current forums are built on different software packages. I am aware that most of the time, there is no need for <br> tags within <pre> preformat tags, but apparently this ColdFusion forum does require the line breaks. You can correspond with Mudcat owner Max Spiegel about it if you's like - he's max@mudcat.org. -Joe- |
|
Subject: RE: Mudcat rewriting preformatted text From: Jack Campin Date: 13 May 11 - 02:33 PM Joe, I already tried what you suggested: If I turn off automatic linebreaks, the tune ends up on one line, disregarding what <pre> is suposed to achieve. If I then add tags to the end of each line to force a linebreak (which shouldn't be necessary) Mudcat inserts a leading space after it. There is NO NEED to edit stuff within "pre" tags at all. If the browser can interpret the character encoding, the linebreaks will appear where the author typed them. That's how "pre" is specified to work. The only change that may be necessary is to change the character encoding of what gets entered to whatever Mudcat uses (which is not declared anywhere, but browsers always seem to guess right). I use "pre" a lot on my pages (the song lyrics in "Embro, Embro"). Nobody's ever reported having a problem with it. And I don't use any "br" tags to force linebreaks within the "pre" stuff. |
|
Subject: RE: Mudcat rewriting preformatted text From: GUEST,Grishka Date: 13 May 11 - 12:14 PM Here is one of the posts I was talking about. The poster Ceto used for every other space, which I found a good idea (so I copied it shamelessly). My own post to that thread used <pre>, which indeed produces leading blanks. Probably I unchecked "automatic linebreaks". I was new to ABC and to Mudcat then. The is changed to an ordinary space when copied from Internet Explorer. But abcm2ps seems to simply ignore a genuine NBSP (Unicode A0). |
|
Subject: RE: Mudcat rewriting preformatted text From: GUEST,Jon Date: 13 May 11 - 05:11 AM I don't think the brs are a problem. The exist regardless of whether or not pre is used and should wind up as line breaks when the abc is copy pasted. It seems to me it is just the added leading spaces that cause problems for some abc software.
-Joe Offer- |
|
Subject: RE: Mudcat rewriting preformatted text From: Joe Offer Date: 13 May 11 - 01:34 AM Jack, have you tried entering the <br> line breaks manually or in Word, unchecking the "automatic line breaks" on Mudcat, and then pasting in the ABC? -Joe- |
|
Subject: RE: Mudcat rewriting preformatted text From: Artful Codger Date: 13 May 11 - 01:12 AM Another alternative is to replace all spaces with non-breaking spaces. I'm not sure how ABC programs respond to that, however. |
|
Subject: RE: Mudcat rewriting preformatted text From: Jack Campin Date: 12 May 11 - 02:26 PM Not quite - <code> ... </code> gets some spaces replaced by tabs, which screws up the monospaced alignment. (It was probably me you saw trying it). |
|
Subject: RE: Mudcat rewriting preformatted text From: GUEST,Grishka Date: 12 May 11 - 02:23 PM The problem is not new, it is one of many related ones, known for ages. I doubt they will ever be solved; Max seems to be considering a completely new software off the shelf. I saw someone use <code> ... </code> instead of "pre", which works as desired. |
|
Subject: RE: Mudcat rewriting preformatted text From: Bill D Date: 12 May 11 - 11:05 AM I see, Jack. Since I have no idea what would be require to alter that setup..(I think you have made a couple of suggestions before).. and since Max must do any changes himself, instead of have his former expert programmer, Jeff, play with it, it 'may' be hard to implement. Have you tried contacting Max directly with technical suggestions? |
|
Subject: RE: Mudcat rewriting preformatted text From: Jack Campin Date: 12 May 11 - 10:53 AM If you don't care about the spacing, you can enter ABC and have it copy correctly into an ABC processor. Bruce Olson's stuff was like that. It works (at least if you allow for it being developed on ABC2WIN) but it's horrible to read. But I'm careful about the layout of ABC source. It's far more readable, and far more likely to be accurate, if you align parallel phrases vertically along barlines. Which means using monospaced fonts and no spacing adjustments by auto-tabbing. Mudcat is making it impossible for me to have both source readability and machine processability at the same time. |
|
Subject: RE: Mudcat rewriting preformatted text From: DMcG Date: 12 May 11 - 10:28 AM And this thread was created a day or to ago and seems ok - I highlighted the ABC and copy-pasted into Notepad without anything odd appearing. |
|
Subject: RE: Mudcat rewriting preformatted text From: Bill D Date: 12 May 11 - 10:20 AM for example, see this thread |
|
Subject: RE: Mudcat rewriting preformatted text From: GUEST,leeneia Date: 12 May 11 - 10:14 AM My experiment worked fine as far as line length. I should not have put in the returns. Good to know. |
|
Subject: RE: Mudcat rewriting preformatted text From: Bill D Date: 12 May 11 - 10:12 AM hmmm.. I know that ABC tunes HAVE been entered here many times, looking as they were supposed to look. Bruce Olson used to do them, as did Alan of OZ. I'm not sure if there have been recent changes. |
|
Subject: RE: Mudcat rewriting preformatted text From: GUEST,leeneia Date: 12 May 11 - 09:59 AM Let's see. Am I supposed to put returns after the lines? I'll try it that way, since that seems natural. How brightly beams the morning star! What sudden radiance from afar doth cheer us with its shining? Newly truly God's word feeds us rightly leads us truth bestowing. Praise, oh, praise such love o'erflowing! |
|
Subject: RE: Mudcat rewriting preformatted text From: Jeri Date: 12 May 11 - 09:54 AM I think I get it now. The problem is the space Mudcat adds at the start of every line, automatic line breaks or manually entered breaks. The long line is just a mess. |
|
Subject: RE: Mudcat rewriting preformatted text From: Jack Campin Date: 12 May 11 - 09:51 AM What would be helpful would be for Mudcat simply to LEAVE MY INPUT ALONE and let the browser interpret <pre> correctly. If I turn off automatic linebreaks, the tune ends up on one line, disregarding what <pre> is suposed to achieve. If I then add <br> tags to the end of each line to force a linebreak (which shouldn't be necessary) Mudcat inserts a leading space after it. There seems to be no way to enter an ABC tune into Mudcat without it being sabotaged one way or the other. |
|
Subject: RE: Mudcat rewriting preformatted text From: Jeri Date: 12 May 11 - 09:30 AM I think you either get the line breaks, or you get one non-breaking line. Some sort of "wrap" feature would be helpful here. |
|
Subject: RE: Mudcat rewriting preformatted text From: Jeri Date: 12 May 11 - 09:27 AM You didn't have the "Automatic Linebreaks" box checked did you? I think it automatically inserts line breaks where it LOOKS like the line ended, and if you un-check it, it will just keep going on and on. Just like this message, if it all works. |
|
Subject: Mudcat rewriting preformatted text From: Jack Campin Date: 12 May 11 - 05:34 AM This is a bug. Try entering some text surrounded by <PRE>... </PRE> tags. It should display exactly the way it was typed in, in a monospace font. (Which monospace font being up the browser). But that isn't what Mudcat does. Any time you enter text like that, Mudcat changes it so that each line is preceded by <br> and a space. There is nothing the user's browser can do to reverse this. The result is that if you copy a preformatted ABC tune out of a Mudcat thread, your ABC processor won't recognize it as being a tune. (ABC never uses leading spaces in its header section). Preformatting is very useful if you're trying to make ABC look readable. How about fixing this? Retrospectively would be good, but at least stop the input routines from rewriting any more preformatted text. |
| Share Thread: |