Which approach is best for creating PostScript in

2019-08-23 05:37发布

问题:

I need to create PostScript output from our system. Our system produces highly formatted documents to numerous formats and I need to add .ps as an additional format.

One bit of weirdness, our code is all written in Java and we use IKVM for the .net version of our library. We have about 5% of the code written in C# and the rest is Java converted with IKVM.

I create .ps files on the Java side using a library that allows me to write to a Graphics2D object it provides. Unfortunately, in .NET (via IKVM) it's horribly slow.

So, to solve this, I'm thinking:

  1. Go into the IKVM code and see if I can speed this up. It makes no sense that it is so slow.
    • Advantage, if it works it’s probably the fastest resolution. And now future Graphics2D libraries can be used.
    • Disadvantage, if I can’t, I’ve wasted time. Also, going forward we’ll have our own IKVM branch.
  2. Investigate oreasoft – if that works, use that with a PostScriptBuilder
    • Advantage, this should be pretty fast and fully & correctly handle .ps.
    • Disadvantage, this only solves the problem for .ps. Also 5K/year for a format we may not get many sales on.
    • In this case I would do a GraphicsBuilder for bitmap & .wmf output – that would be quick & easy.
  3. Create a .net Graphics object based library for .ps. And then just like the Graphics2DOutputBuilder in Java, create a GraphicsOutputBuilder in .net
    • Advantage, this is the cleanest correct-est way to do this. And we can easily add bitmap & .emf output this way (they have a Graphic object way to write to them).
    • Disadvantage, this is substantial work and we may have ongoing small issues as we learn all the details of PostScript.
  4. Rewrite the Apache xml-graphics library to use .net calls instead of Java calls for the code in it.
    • Advantage, this is probably a bit less work than the Graphics approach.
    • Disadvantage, when done we have this but any future formats, like SVG, we have to also re-write in full.

I appreciate any feedback on solving this problem.

回答1:

We’ll be creating a branch of IKVM (tentative name Windward MVKI) and we’ll put it up on NuGet.

The issue we found is in converter.cs – C2J.ConvertShape(). It accesses path.PathPoints[i]. The problem is on each call to that it creates the array of points. Moving the call to PathPoints outside the for loop and then accessing the copy of the array built once to access speeds it up – a lot.

In other words:

for (int i = 0; i < points.Length; i++) {
PointF point = path.PathPoints[i];

Is changed to:

PointF[] points = path.PathPoints;
for (int i = 0; i < points.Length; i++) {
PointF point = points[i];