First of all I love all the work you've put into this tool. Now I was wondering if there is a way to trick the tool to use the artifact frame for colorless cards, like Devoid cards? Cause right now it returns a transparent frame, while still using the crop art rather than the full art.

running jdk 17.0.1 and proximity 0.4.0 is working but proximity 0.5.0 and 0.5.1 not working, getting below messages: WARNING: A terminally deprecated method in java.lang.System has been called WARNING: System::setSecurityManager has been called by dev.hephaestus.proximity.Main WARNING: Please consider reporting this to the maintainers of dev.hephaestus.proximity.Main WARNING: System::setSecurityManager will be removed in a future release ERROR [Proximity] Cannot invoke "java.nio.file.Path.getFileSystem()" because "path" is null

using version 0.5.2

getting an error using long dash in type_line override the below type line was copied from scryfall and the word Creature removed but throws error due to an issue with the long dash

Ertai, the Corrupted --override=type_line:"Legendary — Phyrexian Human Wizard"

java.nio.charset.MalformedInputException: Input length = 1 at java.base/java.nio.charset.CoderResult.throwException(CoderResult.java:274) at java.base/sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326) at java.base/sun.nio.cs.StreamDecoder.read(StreamDecoder.java:188) at java.base/java.io.InputStreamReader.read(InputStreamReader.java:177) at java.base/java.io.BufferedReader.fill(BufferedReader.java:162) at java.base/java.io.BufferedReader.readLine(BufferedReader.java:329) at java.base/java.io.BufferedReader.readLine(BufferedReader.java:396) at dev.hephaestus.proximity.Main.loadCardsFromFile(Main.java:74) at dev.hephaestus.proximity.Main.lambda$main$2(Main.java:57) at dev.hephaestus.proximity.util.Result.then(Result.java:45) at dev.hephaestus.proximity.Main.main(Main.java:56)

Implements a resolver for finding local art. This resolver looks in a folder called art located at $PWD at the time of execution (i.e. next to the proximity.jar, or in the root of the java project).

If no local art is found, or the art directory doesn't exist, it falls back to using the old resolver.

If the --use_official_art flag is not set to true, the ArtLayer won't be rendered anyway.

There are some caveats to this implementation that I would like some input on, and I am not entire sure how we should handle it. I implemented a way to assign a set to an image, and if a set it assigned, it trumps images with a set assigned (given that you try to render a card of said set). But every card that is rendered has a set by default, since scryfall defaults to the latest printing of a card if no set is explicitly assigned.

So say you want to render:

1 Counterspell
1 Counterspell (MH2)

And you got two images:

art/counterspell.jpg
art/mh2/counterspell.jpg

In this case, I would assume the creator would like one counterspell of each art to be rendered, since they assigned set to one of them and not to the other. But in reality, since MH2 is the most recent printing of counterspell, they would get two counterspell with the MH2 art.

I am not entirely sure how we could work around this. One solution would be to just accept it, and move on. Another would be to add a property to the RenderableCard object where you can see if set comes from the Scryfall responses or from the cards file, and we can assign art by only using the set code from the cards file.

When trying out set SVG set symbols from CCGHQ forums (https://www.slightlymagic.net/forum/viewtopic.php?f=15&t=7010) I encountered an NPE during processing (SVGLayerRendered.java, line 53). This is due to SVG files missing viewbox attribute in the svg element, only width/height attributes are present as seen in the sample: R.svg.txt.

Current code for this looks like this:

SVGRect svgBounds = root.getViewBox().getBaseVal();
double svgWidth = svgBounds.getWidth(), svgHeight = svgBounds.getHeight();

Unfortunately the batik API doesn't have a simple way of checking if the viewbox attribute is available, so a simple workaround I'm using right now uses this:

double svgWidth, svgHeight;
SVGRect svgBounds = root.getViewBox().getBaseVal();
try {
  svgWidth = svgBounds.getWidth();
  svgHeight = svgBounds.getHeight();
}
catch (Exception ex) {
    svgWidth = root.getWidth().getBaseVal().getValue();
    svgHeight = root.getHeight().getBaseVal().getValue();
    svgBounds.setX(0);
    svgBounds.setY(0);
    svgBounds.setWidth((float)svgWidth);
    svgBounds.setHeight((float)svgHeight);
}

But I suppose it can be made even better...

Hi, first of all thanks for the repo, super cool.

I was testing version 0.4.0 a couple of weeks ago and I had no problem whatsoever. However, moving to 0.5.x, I get the following stack:

INFO  [Proximity] Fetching info for 1 cards...
1/1
INFO  [Proximity] Successfully found 1 cards. Took 512ms
INFO  [Proximity] Rendering 1 cards on 1 threads
ERROR [Proximity] 0/1     41ms  Sword of Feast and Famine                               FAILED
ERROR [Proximity] Cannot invoke "java.nio.file.Path.getFileSystem()" because "path" is null
DEBUG [Proximity] java.base/java.nio.file.Files.provider(Files.java:105)
DEBUG [Proximity] java.base/java.nio.file.Files.isDirectory(Files.java:2316)
DEBUG [Proximity] dev.hephaestus.proximity.Proximity.save(Proximity.java:458)
DEBUG [Proximity] dev.hephaestus.proximity.Proximity.render(Proximity.java:440)
DEBUG [Proximity] dev.hephaestus.proximity.Proximity.renderAndSave(Proximity.java:397)
DEBUG [Proximity] dev.hephaestus.proximity.util.Result.then(Result.java:45)
DEBUG [Proximity] dev.hephaestus.proximity.Proximity.run(Proximity.java:87)
DEBUG [Proximity] dev.hephaestus.proximity.util.Result.ifPresent(Result.java:66)
DEBUG [Proximity] dev.hephaestus.proximity.Main.main(Main.java:60)
INFO  [Proximity] Done! Took 563ms

I am running java -jar proximity-0.5.2.jar --cards=card_list.txt --template=chillis.zip from a docker image based on openjdk:16 (openjdk:17 works all the same). Build 0.4.0 still works fine, though.

Any idea where this might be coming from? Thanks!

When generating a card of of the Ubuntu docker image, I get the following bottom line:

But when I generate images from my Mac, I get the following bottom line:

I don't know if this is an issue with my docker image, or if it is an image with native fonts on Ubuntu

Compared a Proximity render to other existing scans in Photoshop and the Artist Name font is off and the size is too big by what looks to be about 2 points.

Top line is Proximity, bottom one is existing card scan

Wiki getting started instructions mention creating a templates directory, but it looks like both that and a templates_overrides directory are required as there's an explicit load of it here.

https://github.com/Haven-King/Proximity/blob/ce870d9403244de55801e19a94e88c09c0d5b291/src/main/java/dev/hephaestus/proximity/Main.java#L140

The exception message thrown doesn't mention the path it was trying, so it's a bit hard to diagnose what the issue is.

https://github.com/Haven-King/Proximity/blob/ce870d9403244de55801e19a94e88c09c0d5b291/src/main/java/dev/hephaestus/proximity/templates/FileSystemTemplateSource.java#L30

Both versions of java I have installed on my machine (OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.9.1+1) and Java(TM) SE Runtime Environment (build 1.8.0_251-b08)) were built in 2020 and yet neither of them is even close to being able to run the jars built on the release page. I bet most other people's versions of Java are even older.

When I try and run it, I get this:

Error: LinkageError occurred while loading main class dev.hephaestus.proximity.Main
        java.lang.UnsupportedClassVersionError: dev/hephaestus/proximity/Main has been compiled by a more recent version of the Java Runtime (class file version 60.0), this version of the Java Runtime only recognizes class file versions up to 55.0

Really minor issue, but the render for the backside of transforming double-faced cards is missing the colored circle by the typeline that indicates the card's color. See Avacyn the Purifier as an example. Also, the backside of TDFCs include the front side's power/toughness, which is wrong. Only the front of a TDFC includes reminder power/toughness for the back. Not the other way around.

having a little issue with the cards Black Market Connections and Dawnbringer Cleric

seems there is some bad synergy when having bullet and italics/dash

testing the issue I overloaded the oracle and can remove bullet or i can remove dash and it works but cannot have both together like that for some reason

Hello @Haven-King !

I've made a Mardown page to explain how to use the myojin223 Ready to Use Proximity.

I can't make a PR for the Wiki page, so I made an Issue here :)

Just having a small issue with 0.5.2 with any cards that have a dash in the card name, the dash is not included in the file name. For example Snow-Covered Forest

Currently Proximity is saving the PNG in RGBA with no or very little compression. The Alpha is needed for people making frames to then edit later but for many use cases it would be nice to have the option to drop the alpha layer as an option.

This is some example file sizes: Lightning Bolt - base M15 template 10.8 MB - PNG - Fresh from Proximity with Alpha layers. RGBA 6.99 MB - PNG - Just optimized the Proximity image keeping the alpha layer 6.20 MB - PNG, no alpha, max compression

I did this compression using Pillow in Python and had basically the same numbers from Photoshop saving the file.

Doesn't render lands like Ancient Tomb or Volrath's Stronghold. Editing line 118 of the XML and changing the value to "true" fixed it for me.