Registered: 2003-01-28
Posts: 4396
Loc: New Jersey
WARNING - the PostPrep.zip attached to this post does not work with Kix32 version 4.63. An update is being tested and will be uploaded when validated.
For those of you that don't know - PostPrep is the Kix script that colorizes kix code, generating HTML that can be pasted directly into a message as you see below, without using Code tags. You must select HTML or HTML/UBB as the message type when posting a message with PostPrep content.
This postprep release runs from a command line -
Kix32 ppcl.kix -s:myscript.kix -c
The postprepped code is placed on the clipboard, ready to paste into a KORG message. The default (without -c) writes a .HTM file with the same name as the source file. Run without args for usage info.
The PostPrep.INI file will be posted in the next message. The script expects this file to be in the path defined by %S_CONFIG%, or - if not there - in @SCRIPTDIR.
This version is quick & easy to use, and is capable of postprepping an entire folder of Kix files automatically. The zip file contains both the GUI and command-line versions of PostPrep, and both share a common configuration file.
Due to the size of this post, it is presented in 3 parts. Parts 1 & 2 are the core script, part 3 is the config file. The code presented here is primarily to illustrate the concept and code structure. You are strongly encouraged to download the entire code set - PostPrep.kxw, PostPrep.ini, PPCL.Kix, and the ReadMe.txt file from the attached zip file. Only the zip file will be updated as versions change!!
Registered: 2002-05-13
Posts: 309
Loc: STRASBOURG, France
What a nice job !!!
but i had some little problems when I copied and pasted to my text editor (same result if I save as in .txt format). Applying ppc.kix to itself gives a wrong result.
1) the following comment line has been broken in two lines !!! ; If the destination file wasn't specified, use the SourceFileSpec and change the extension to ".htm"
2) in "; Set the Border directive based on the flag value", the comment line has been broken in two lines. The second line begins with an extra comma and kixtart considers the begins of the second line has an unknown command.
3) in "; Define the body settings", the correct line should be $Body = '<font face="' instead of $Body = '$I = ReadProfileString($ConfigFile, 'FieldSet', 'TypeFace')
this is because of the < character
4) same as 1) in the enumini function with return nothing. this function always returned an empty array !!!
5) at the end of Kix2HTML function, the $OutBuffer line has been broken and there is an extra comma : $OutBuffer = $OutBuffer + Join(Split(Join(Split(Join(Split(Join($SrcTxt,@CRLF),$1),'&'),,$2),$Lc),$3),$Tc)
Correct line should be : $OutBuffer = $OutBuffer + Join(Split(Join(Split(Join(Split(Join($SrcTxt,@CRLF),$1),'&'),$2),$Lc),$3),$Tc)
With theses changes, I have a result but if I apply the new version of ppc to itself, the result is still wrong. Point 3 should be solved by replacing < character by a variable. Point 1, 2, 3 ou 4 seem to come from the same reason.
Registered: 2002-05-13
Posts: 309
Loc: STRASBOURG, France
Hi,
the problem is the following lines :
Code:
If $Cp > 85 And InStr(Chr(9) + Chr(32) + ',+-/*', $C)
$Line = $Indent + SubStr($Line, $Cp) ; reset the line
$Ll = Len($Line)
$Cp = 0 ; and the pointer
$OBuf = $OBuf + @CRLF ; break the line here
EndIf
if I comment theses lines, the result is correct. may be it is not a good thing to break a line after the 85th column !!!
first, if the line is commented (or end of line), new line should be commented. second, when the line is broken, the last character is repeated at the beginning of the new line. Example :
Registered: 2003-01-28
Posts: 4396
Loc: New Jersey
Christope
Thanks for the feedback!!
I've updated the post, and changed how the long-line wrapping is done. It now works by checking after most characters are added to the output buffer, which fixes the clipped character. The wrap-check function evaluates the original line to determine the indent, and returns the number of chars to indent (+2) if wrapping is needed. The wrap position is now defined in the PostPrep.ini file - the WordWrap was changed from a boolean to a numeric value, indicating at/after which column wrapping should be considered.
I also removed the funky "$Lc + 'font..." type definitions by replacing the "<" and ">" chars with their HTML string equivelents.
Give the new version a go and let me know if you find any more issues.
One caveat with line wrapping - it wraps on space, tab, and these characters: ",+-/*". Since "-" is also a dash/heyphen, I'm thinking about removing that as a breakable character.
Also - when strings are broken, the resulting code may insert a CRLF in the output. The code would be more complex, but creating a "diversion" to hold the string text (with quotes" and breaking before and/or after might be better. Maybe the next release.
For now, the user should be aware that text strings may need to be "repaired" back to single lines. I'm also reviewing the HTML guide - maybe the answer is to insert HTML "soft" spaces?
Glenn
_________________________ Actually I am a Rocket Scientist!
Also - when strings are broken, the resulting code may insert a CRLF in the output. The code would be more complex, but creating a "diversion" to hold the string text (with quotes" and breaking before and/or after might be better. Maybe the next release.
If quoted strings are broken, they should just need to have a closing quote, a concatenation +, and an opening quote on the newline to prevent a multiline embedding.
Easier said than done. :p
_________________________
Give a man a fish and he will be back for more. Slap him with a fish and he will go away forever.
Registered: 2003-01-28
Posts: 4396
Loc: New Jersey
OK - that's actually very easy to accomplish - same logic as handling comments. My biggest concern is - just how much modification of the original code is "OK" for the sake of wrapping long lines?
Glenn
_________________________ Actually I am a Rocket Scientist!
Registered: 2002-05-13
Posts: 309
Loc: STRASBOURG, France
Hi,
one of the last change is worst than the original version. you replace $Lc+' by '< and '+$Tc by >'. This is not a good idea because all strings that look like HTML tag now disappear !!!
other changes seem OK.
one suggestion : i know at least 3 special characters in HTML : <>& at the beginning of Kix2HTM, special char are replaced with chr(1), chr(2), chr(3) at the end of Kix2HTM, why not replace these characters with special HTML tag. I have tried to replace
Registered: 2003-01-28
Posts: 4396
Loc: New Jersey
The whole point is to allow and translate htm code. The problem was that I translated the < and > chars, but did not handle the & - this caused the < and > to be interpredted by the BBS, displaying the line as you saw it, even though that's not what the code was.
I did a compare of the .GEN file and the .HTM file and it reports that the two files are identical except for blanks. This is understandable as Kix2Htm adds a space character to every blank line to preserve formatting.
I think we're good now. (although.. I did just realize I need to add a code block to handle Block Comments.)
Glenn
_________________________ Actually I am a Rocket Scientist!
Registered: 2003-01-28
Posts: 4396
Loc: New Jersey
Updates to the Kix2Htm UDF, as follows: In Kix2Htm() Added support for Block Comments
In WC() If Not $_WF was changed to: If $_Wf = 0
This was done to allow the use of 0 (zero) to disable line wrapping via the WordWrap value in PostPrep.ini. The alternative was to use a very large number, such as 9999, which isn't intuitive.
Also updated the PostPrep.ini file with new function references.
Attached a ZIP file with the complete code and INI file.
Glenn
_________________________ Actually I am a Rocket Scientist!
Registered: 2003-01-28
Posts: 4396
Loc: New Jersey
Updates!
Version is now 2.1.0.0 for both GUI and C/L versions
GUI and C/L versions share a common code base.
New zip file attached to first post - PostPrep.zip - replaces PPCL.ZIP.
ZIP file now contains both the GUI and command-line versions, and both share a common configuration file.
The command-line version now supports a -W switch, which is designed to generate .HTM files from an entire folder of .KIX, .UDF, or .KXF files. This is how I publish my UDF library on my web site, automatically updated every night.
The GUI utilizes separate tabbed windows to display script source, HTML, and colorized preview. Launching IE is no longer required to preview the PostPrepped code.
Kix2HTM UDF has been updated (minor) to insert a Global var called $NOTICE, which adds a comment to the HTML indicating the method and version of PostPrep that was used. This will aid in identifying version-specific issues.
Glenn
_________________________ Actually I am a Rocket Scientist!
Registered: 2003-01-28
Posts: 4396
Loc: New Jersey
Minor modification based on UBB post testing. Both versions will display a warning if the generated HTML is larger than 65500 characters - 64K or the current UBB post size limit. It will not affect generation of the HTML, it will only display a warning.
Updated the ZIP file in post #1.
Glenn
_________________________ Actually I am a Rocket Scientist!
now as the ubb code has been cracked to comply with long line police rules, you should edit the postprep to support it as well. so, in the code's pre-field <pre> add the class: <pre class="ubbcode-body">
I just have to say Glenn, you have so many comments in the kix2htm that I can't see any of my handywork in there anymore... not even able to tell if there is any left. makes me sad :P