PDF Print display issue

[kendallroth]

When I attempted to print a markdown document converted using vmd, I ran into some strange display issues. Both l (lowercase) and I (uppercase) are rendered strangely, as shown in the attached image. Additionally, the table header is duplicated at the top of the page, causing it to overlay the page text. The Markdown is properly formatted (ie. spaces beneath headers, etc) as far as I can tell.

This image is an example PDF page, with the middle content cut out:

[maxkueng]

Yeah, that's weird. Can you attach or link the document so I can reproduce it? Or paste some Markdown text that causes the problem?

[kendallroth]

As far as I can tell, any text with either l or I causes the issue for me. I've also noticed that the spacing in bulleted lists is somewhat larger than expected (and than GitHub displays it), and code blocks have no background color.

Link to PDF: osgi.pdf Link to Markdown: Can't attach .md files

• Markdown is below

---

# OSGi

**OSGi — Open Service Gateway Initiative**

- OSGi is a Java framework for developing and deploying modular software programs and libraries.
    1. Specification for modular components called bundles, commonly referred to as plug-ins. The specification defines an infrastructure for a bundle's life cycle and determines how bundles will interact.
    2. The second part of OSGi is a Java Virtual Machine (JVM)-level service registry that bundles can use to publish, discover and bind to services in a service-oriented architecture (SOA).
- OSGi provides a way that bundles can communicate with each other without being coupled together (interfaces, etc)

## Summary
**Note**: _Bundle_ and _plug-in_ can be used interchangeably; _plug-in_ is preferred by Eclipse, _bundle_ is preferred by OSGi.

Most applications consist of several different parts, called modules or components, which interact with each other through an Application Programming Interface, or API. The API is considered to be the classes/methods which are accessible to other components. A component also has a set of classes/methods that are considered internal. Using an API from another component creates a dependency on the component, as it now requires the other component to be present in order to work correctly. Currently, Java doesn't provide a structured way to describe the various dependencies of a component; rather, every public class can be called from another component.

OSGi is a specification framework that defines a component and service model for creating loosely coupled modular bundles. Each bundle can define its API through a set of exported packages and also specify its own required dependencies.

## Bundles
A bundle can define exports or dependencies on other bundles in its manifest file. OSGi prevents access to classes without a defined dependency (except for packages from the Java runtime). Dependencies can be defined as either bundle or package dependencies. Bundle dependencies enable accessing all exported packages from the bundle while package dependencies enable accessing a specific package without worrying what bundle exports it (enabling a later change). The OSGi runtime **ensures that all dependencies are present before starting a plugin**, activating them if necessary.

### Bundle Lifecycle

| # | Status      | Description
|---|-------------|-------------|
| 1 | Installed   | Bundle has been installed
| 2 | Resolved    | All bundle dependencies have been resolved
| 3 | Starting    | Bundle is starting
| 4 | Active      | Bundle has started and is running
| 5 | Stopping    | Bundle is stopping
| 6 | Resolved    | _N/A_
| 7 | Uninstalled | Bundle has been uninstalled

**NOTE:** Bundles must all contain an `Activator` class that is responsible for managing the bundle's life cycle, including a `start()` and `stop()` set of methods. These methods are responsible for handling any necessary preparation or clean up during the beginning and end of the bundle's life cycle.

## Declarative Services
A _service_ in OSGi is defined by a standard Java class or interface, composed of the class/interface for which you want to provide a service and the implementation class for the service interface. This enables switching out the service implementation but still using the existing service interface. Services can be dynamically stopped/started, so bundles that use these services must be able to handle this behaviour, typically done by the `ServiceListener` handlers.

It is good practice to define a service with a bundle that contains only the service interface definition, with another bundle providing the service implementation. This way, the implementation of the service can always be changed at a later time. Since dependent bundles only communicate with the service through the service interface, updating the service implementation should not break existing dependent bundles. For example, if an existing implementation used a SQL database to persist data but the developers wanted to switch to another database vendor, the only requirement would be that the new implementation correctly supports the existing service interface.

`This is a code sample with no background color?`

```java
//Sample Java code
public void sampleMethod(String input) {
    if (input.equals("test")) {
        return true;
    }
    return false;
}
```

_Declarative Services_ remove the need for registering and consuming services programmatically. Instead, _Declarative Services_ can be declared by a _Component Definition_ file, which is either manually configured or rendered automatically by Eclipse annotations (which will also update the MANIFEST).

## List of Lifecycle Methods (duplicate)
- Installed
    - Bundle has been installed
- Resolved
    - All bundle dependencies have been resolved
        - This can cause problems?
- Starting
- Active
    - Bundle has been started and is running

**NOTE:** A _Service Component Runtime_ bundle **must** be installed and activated on the device if using Declarative Services. However, this bundle will likely already be installed as part of the environment.

[kendallroth]

A bit more research shows that I am having trouble printing all markdown documents to PDFs, not just using your tool. However, the only issue I can replicate is the thick lines on l and I characters. The rest seem to be specific.

[lfilho]

I'm also having the table header being duplicated on every page's top section... The Is and ls seem fine, though.

Using latest version (1.29.1), installed via npm on node 8.2.1 (also latest as of this writing). I'm under Macos Sierra.

[maxkueng]

I was able to reproduce the problem with older versions of vmd.

Now I have tried it again in vmd 1.31.0 with Electron 1.7.6 and with the markdown document from @kendallroth and the PDF output looks great.

@kendallroth, @lfilho: Can you upgrade vmd to the latest version and try again?

[maxkueng]

Closing this because I can't reproduce the problem anymore in the latest version of vmd, and due to lack of activity in the issue comments.