JDisplay : Java Glossary

*0-9ABCDEFGHIJKLMNOPQRSTUVWXYZ (all)
The JDisplay Java Applet displays the large program listings on this web page. JDisplay requires an up-to-date browser and Java version 1.7+, preferably 1.8.0_25. If you can’t see the listings, or if you just want to learn more about JDisplay, click  here for help. Use Chrome for best results.
The CurrCon Java Applet displays prices on this web page converted with today’s exchange rates into your local international currency, e.g. Euros, US dollars, Canadian dollars, British Pounds, Indian Rupees… CurrCon requires an up-to-date browser and Java version 1.7 or later, preferably 1.8.0_25. If you can’t see the prices in your local currency, Troubleshoot. Use Chrome for best results.

JDisplay icon  JDisplay
How It Works Improving the Look
Advantages of Various Rendering Techniques Why
Under the Hood Extending JDisplay
JDisplay, Firewalls and MIME Types Links

JDisplay is an Applet and back end to create the various colourised listings you see all over my website. I released the source. It consists of parsers for Java, HTML (Hypertext Markup Language), SQL (Standard Query Language), XML (extensible Markup Language), and BAT (Batch) files that decide the colours, and an Applet to display and scroll the listings, and a macro preprocessor to either expand small listings as HTML inline or generate an <applet invocation to an Applet to display it. If you can’t see the listings, here are things to check:

Java powered Get New Java Get New Browser help

How It Works

JDisplay renders three different ways:
  1. Inline

    java.exe -version
  2. With an iframe

  3. With an Applet

    view
If you don’t see anything, check out first that you can see Applets in general by looking at sample Applets and my Applet Collection, especially Wassup which will tell you which Java version you have installed. If no Applets work, try tracking down the problem with the help under JRE.

Advantages of Various Rendering Techniques

Under the Hood

The JDisplay program is more complicated that you would imagine, so you probably don’t want to be bothered with it just to display a few listings. I use static macros to generate the HTML, but you could generate it by hand.

One project on my plate is offering a free webservice to convert your listings to colourised HTML.

JDisplay, Firewalls and MIME (Multipurpose Internet Mail Extensions) Types

If the problem is only with JDisplay, then likely the problem is with your firewall interfering the JDisplay getting its listing files. The files have the following mime types and extensions:
JDisplay file extensions and MIME types
Extension MIME type
ser application/x-java-serialized-object
bat text/plain
batfrag text/plain
java text/x-java-source
javafrag text/x-java-source
html text/html
htmlfrag text/html
sql text/plain
sqlfrag text/plain
xml application/xml
xmlfrag application/xml
If *.ser files are blocked, you will not see anything. If any of the others are blocked, the download button will fail.

While you are at it, you might as well check the complete list of MIME types to make sure you are not blocking any other critical kinds of file downloads.

Improving the Look

JDisplay and my website in general were designed with certain fonts in mind. If you don’t have them installed Java and your browser will substitute others, which won’t have the same metrics which means it might not look right. I suggest you install the following fonts:
Suggested Fonts For Viewing Mindprod.com
Font Source Cost
CurrCon Applet needs Java 1.7 or later to display prices in your local currency.
CurrCon Applet needs Java 1.7 or later to display prices in your local currency.
Bitstream Vera Sans Mono gnome.org. This is my primary monospaced font. free
Tiresias PCFont Z Bitstream MyFonts.com. A highly legible font. This is my primary proportional font. $24.75 USD .
Lucida Console Comes with Windows. If you don’t have it, you can buy it, and any of the other Lucida family from Ascender Fonts $30.00 USD
Lucida Sans C:\Program Files\java\jre1.8.0_25\ \lib\fonts\LucidaSansRegular.ttf
C:\Program Files\java\jre1.8.0_25\ \lib\fonts\LucidaSansDemiBold.ttf
free
Lucida Sans Typewriter C:\Program Files\java\jre1.8.0_25\ \lib\fonts\LucidaTypewriterRegular.ttf
C:\Program Files\java\jre1.8.0_25\ \lib\fonts\LucidaTypewriterBold.ttf
free
Lucida Bright C:\Program Files\java\jre1.8.0_25\ \lib\fonts\LucidaBrightRegular.ttf
C:\Program Files\java\jre1.8.0_25\ \lib\fonts\LucidaBrightDemiBold.ttf
C:\Program Files\java\jre1.8.0_25\ \lib\fonts\LucidaBrightItalic.ttf
C:\Program Files\java\jre1.8.0_25\ \lib\fonts\LucidaBrightDemiItalic.ttf
free
Tiresias Keyfont V2 download. For labelling keycaps. free
If the fonts or the displays look flea-bitten, make sure you have anti-aliasing turned on.

Why JDisplay ?

People have often asked me why I don’t just embed listings directly in my web pages, perhaps decorated with CSS (Cascading Style Sheets) style tags instead of fooling around with the JDisplay Applet. I do, I generate decorated HTML, but only for short listings. I use <iframes for medium sized ones, and an Applet renderer for long ones. For long ones, the data that the JDisplay Applet uses are much more compact than the equivalent HTML. With JDisplay, a long listing takes up only a small window on your screen. You an ignore it if you are not interested. Inline listings would create a huge long document to scroll through.

If you don’t have Java at all, you should see a button to download the listing to view in place of the listing. The problem comes when you have a malfunctioning Java. Then you won’t see anything at all.

Further, I am a Java evangelist. In particular I want to see more client-side Java computing. I think this 100% server logic talking to a browser, all the rage these days, is so sixties. So I demonstrate it where I can on my site with JDisplay, the CurrCon currency displays, and the many amanuenses Applets.

Extending JDisplay

You can add your own parsers to tokenize and colourise other languages or types of structured text documents. Here are suggested steps to write your own parser:

  1. Find a Tokenizer that for a language similar to what you want to do. There currently exist ones for bat, C, http (headers), html, ini, java, mft, properties, sql and plain text. Some tokenizer handle multiple extensions. On my todo list are tokenizers for CSS (partially complete), C source and ASM (Assembler) source.
  2. Look in com.mindprod.jprep where the XXXTokeniser decides which file extensions to handle, XXXState is the finite state machine for parsing the code. It does not have the luxury of giving up if the text is malformed.
  3. Look in com.mindprod.jtoken for the tokens. Each token represents a chunk of text that is displayed with a single CSS classes, i.e. it has the same font, size and colour, though you can get fancy displaying within token if you really want. It is a logical chunk of text that is considered a fundamental unit.
  4. Glance at com.mindprod.jdisplay where you will find the code that renders your lists of token. It will not need changing.
  5. You can ignore com.mindprod.htmlmacros.JDisplay, the macro generator that will expand and render your tokens three ways and insert them into HTML. It will not need any changes either.
  6. Write your XXXTokeniser decides which file extensions to handle.
  7. Hook up your XXXTokeniser code into com.mindprod.jprep.JPrep.prepareAllSnippetsForOneDirectory() so it will invoke your tokeniser when it encounters a file of one of the extensions it handles.
  8. Write your XXXCharCategory class to categorise which characters have special meaning in the text you will process.
  9. Compose new CSS styles in the style sheet, possibly separate from your main one, so it only need be include on pages that use Display. This requires you to make up your mind about fonts, colours and sizes of each token.
  10. Do a mockup colourising some text in your language with your new styles. This will help you notice if you have forgotten something, or if the results are ugly or the contrasts are to garish or too subtle. The CSS classes you create will define the tokens and token names you use in your Java Token classes. It is a lot easier to play with your mockup and style sheet to experiment with colour and font schemes than with Java code.
  11. Include the new colours in the Java source code for com.mindprod.jtoken.TokenPalette following the established naming convention. It would probably be safer to put your colour purpose names in a private file, or to factor them out later.
  12. Associate your tokens with colour names in the Java source code for com.mindprod.jtoken.TokenColourScheme following the established naming convention, by defining colour purpose names. This sounds complicated, but if you look at the existing code, you will see this is easy but tedious. It would probably be safer to put your colour purpose names in a private file, or to factor them out later.
  13. Write you various Token classes to control on the fonts, sizes colours and CSS styles of various chunks of text in your rendered text. You can use ones in the common section, but don’t use tokens from other parsers. Just clone them.
  14. Work out what your finite states will be, or work them out for a subset of the entire problem. Build a giant nested case, for what you do when each character category comes in when you are in each state. Just get the framework complete, with all states and character category cases in alpha order. You could use a parser generator like JavaCC, ANTLR (Another Tool for Language Recognition) or YACC (Yet Another Compiler Compiler) to create your parser, and then traverse the parse tree emitting JDisplay-style tokens to a *.ser file. I avoided that approach for thrree reasons:

    1. For some reason, I find writing state machines profoundly relaxing and satisfying. I derive immense joy from watching them work right off the bat as a whole, even when I created them thinking only about minute fraction of the problem at a time.
    2. Generated parsers tend to freak at imperfect code. They can’t even complain coherently. A lowly colouriser has no business complaining. It has to parse code fragments which are necessarily grammically incorrect according the language specs.
    3. My hand-coded parsers are wicked fast.

    But go ahead and try it that way.

  15. Thinking only about one state and one character category at the time, work out what to do and what state to go into next.
  16. Cannibalise freely from other finite state machines.
  17. Proofread, and desk check your finite state machine against some printed text.
  18. Debug/single step your finite state machine so you can see it is behaving as you expected.
  19. Throw all the text you can find at it, including malformed text to see if it is rendering as you expect.
  20. Test out the three modes of rendering, inline, iframe, and Java Applet. It is fairly easy to get the colours, fonts and sizes of the rendering done by Java and by CSS styles out of sync. This does no great harm, so long as both look ok, but I like to keep them 100% consistent.
  21. Pass your code back to me for inclusion in the JDisplay packing if you are willing to share it.

Here in the mockup I am working on for the CSS parser:

a.affiliate:link, a.affiliate:hover, ul>li {
   background : url(image/link/affiliate.png) transparent no-repeat scroll 100% 70%;
   padding-right: 12px; // a comment
   padding-top: 6px !important; /* this is also a comment */
   color : #bb00bb /*! loganberry !*/
}

This page is posted
on the web at:

http://mindprod.com/jgloss/jdisplay.html

Optional Replicator mirror
of mindprod.com
on local hard disk J:

J:\mindprod\jgloss\jdisplay.html
logo
Please the feedback from other visitors, or your own feedback about the site.
Contact Roedy. Please feel free to link to this page without explicit permission.
no blog for this page
IP:[65.110.21.43]
Your face IP:[54.211.235.255]
You are visitor number