There is a sticky topic (in General Discussion) about putting libraries files in Processing.
The needed import statement should be provided by the library itself.
What you see after import is actually not a prefix nor a suffix, but a kind of path, unique identifier of the library, designed to avoid clashes and ambiguity between libraries of various origin. For example, we can find XMLElement in Processing itself, proXML and even various other libraries on the Net. Not to say about generic name like Document!
So the tradition/recommendation made by Sun is to use a domain name as prefix: org.apache, org.codehaus, etc. (org is often used in open source software... we can also find edu.umd.cs (from university), or com.foobar or net.xyz.
Then, we have in general the name of the library, or a more complex path: org.apache.httpcomponents:httpclient, edu.umd.cs.piccolo, org.codehaus.jackson.schema, the latter being found in jackson-mapper-asl-1.6.0.jar. As you see, paths can be unrelated to the jar name, and you can find there several path (eg. org.codehaus.jackson.map.jsontype).
If you cannot find this path in the doc (unlikely), you can find it by opening the jar with an archive manager like 7-Zip: you will find a folder named org (for example - can be several folders, there is always a META-INF folder too), holding a folder (or more) named codehaus, then another named jackson, etc. The folder names map to the package names.
In the Processing world, authors often simplify their package name (sometime because they don't have definitive URL), so you can find import peasy.* or import controlP5.* (this one breaks the tradition of using only lower case chars in package names).
Fonts: if they are installed on the system, you should be able to see them in the Create Font menu.
Loading User Profile...
Login with Facebook