ok, i see what you mean.  I missed the part about putting it in a ticket. However, putting an article in a ticket is just one thing you might want to do with it.

The purpose of "markdown" is to be a markup language that is not very complex so that it provides useful formatting both when viewed in it's raw source AND when parsed into html. 

It's similar to the concept of many wiki editors.

E.g. this is very readable in both formats:
*Taken from [http://docs.phplist.com/SetupCronJob](http://docs.phplist.com/SetupCronJob)*

Your schedule will be of the format 
    * * * * * 
E.g. Every Monday at 1am is: 
    0 1 * * 1

More specifically the format is: 
    ------------- minute (0 - 59) 
    | ----------- hour (0 - 23) 
    | | --------- day of month (1 - 31) 
    | | | ------- month (1 - 12) 
    | | | | ----- day of week (0 - 6) (Sunday=0) 
    | | | | | 
    * * * * * 

You can use several operators for specifying scheduling values. These are the ones commonly used:           

* The comma (',') operator specifies a list of values, for example: "1,3,4,7,8"
* The dash ('-') operator specifies a range of values, for example: "1-6", which is equivalent to "1,2,3,4,5,6"
* The asterisk ('\*') operator specifies all possible values for a field. For example, an asterisk in the hour time field would be equivalent to 'every hour'.
* The slash ('/') is an operator -available with some extended versions of cron support- which can be used to skip a given number of values.

Examples: 
------------
* I want the script to run every 15 minutes starting at 5 p.m. (17) and running through 11:00 p.m. (23). This should happen Mon. (2) through Fri. (6). 
        */15 17-23 * * 2,3,4,5,6
* Same thing as above, except runs it at midnight as well (0). (as an aside, this means it will run at 12:00, 12:15, 12:30 and 12:45.) 
        */15 0 * * 2,3,4,5,6
* Sets the script to run from 1 a.m. to 6 a.m. (every 15 minutes) only on Mon., Wed., and Fri. 
    */15 1-6 * * 2,4,6
* Script starting at 1 a.m. Tue., Thu., and Sat. 
    10 1 * * 3,5,7

There is no option within the ticket to use markdown though. Only within the KB article. What is the point of making markdown usage available in the KB if it will not keep the formatting when you attach it to a ticket?

when you "use markdown" then it will parse some html.  If you do not use that then it treat them as text

This answered most of my questions, but I have a separate issue as well. I entered in the KB like so as a simple test
(This is about the k1000 btw)

<p>REPORTS
</p>
<p>When making a report if there are too many columns for landscape page printing, it will not let you save.
</p>
<ol>
  <li>Go to the Layout Page, you should be here if you received the error (final page with option to save report)</li>
  <li> Click the title of your report, it should be just above your reporting fields on the left in parentheses. </li>
  <li>Next hover down to Page Size and then select Custom Page Size</li>
</ol>
<p>There is a .docx attachment with this KB article that includes screenshots.
</p>


But when I append information from a KB into a ticket, it shows it as code, not as formatted text. Is there a solution for this?

I got a notification on this so was this message on the K1000 boards originally and is this about the K1000 Knowledge Base?  If so, my favourite way to create articles that are going to be viewed on the web is to use an editor like Xinha which is a browser pluging that gives me a wysiwyg view. I can copy / paste from other web pages and use the GUI tools for formatting then click apply and all the markup is saved in the KB article.  Of course i check the box "use markdown".

The drawback with this is you cannot them embed the article intoa  ticket using the "KB Article lookup mechanism".  Since the ticket comments and ticket emails are text-based when you do a lookup on a highly marked up document you just get the source and when that is saved it does not strip out the HTML -- even worse it converts the tags into html entities.  e.g.  <tag> becomes  &lt;tag&gt; 

If you intend to view the article:

• only in a ticket:  just use text and no markdown at all.  Trust the editor view and not the saved view.
  
• only in the web view: use a WYSIWYG editor like Xinha and turn on markdown.
  
• in both: check the box and use markup and markdown sparingly. enough to mark itup but not enough to make it hard to read in plain text.
  

Yes, line breaks should be fine, but indents do not translate. I usually try to do some editing when I approve entries to make them look decent. Some simple HTML tags are supported for those familar (good for hyperlinks, bullets, etc.).

Thanks,
Bob

Okay. Figured it out. I had to select "Use Markdown" on the initial editing page.