You can reproduce the problem using the TextFileFormat sample. Add the AIArtboardSuite to TextFileFormatSuites and add IAIArtboards.cpp to the Shared files.

Then add "IAIArtboards.hpp" and <iostream> to the headers in TextFileFormatPlugin.cpp and extra code to the read handler in TextFileFormatPlugin::GoFileFormat (see full function below). This code outputs the document origin and the max artboard bounds and then tries to set an artboard position with an offset of -500,-500 and a size of 1000x1000 points.

Once the plugin has been built and installed in CC 2018, do the following (tested on Mac, but probably same for Windows):

Test 1
Delete the "Adobe Illustrator Prefs" file in ~/Library/Preferences/Adobe Illustrator 22 Settings
Start Illustrator
Create a new document with a size of 1000x1000 points.
Open a txt file so that the TextFileFormatPlugin::GoFileFormat function is called
This gives the following output:
Document origin 0,0
Max artboard bounds -7692,-7691 16383x16383
Artboard bounds ok

Test 2
Delete the "Adobe Illustrator Prefs" file in ~/Library/Preferences/Adobe Illustrator 22 Settings
Start Illustrator
Create a new document with a size of 16383x16383 points.
Open a txt file so that the TextFileFormatPlugin::GoFileFormat function is called
This gives the following output:
Document origin 0,0
Max artboard bounds 0,0 16383x16383
Failed to set artboard bounds

Using this code, the max artboard size always seems to be 16383x16383, but the offset changes based on the "/artboard" setting in the preferences. In our plugin we have seen the max artboard size changing as well as the offset.

ASErr TextFileFormatPlugin::GoFileFormat(AIFileFormatMessage* message)
{
ASErr error = kNoErr;
char pathName[300];

message->GetFilePath().GetFullPath().as_Roman( pathName, 300);

if ( message->option & kFileFormatWrite )
{
// Get whatever art is supposed to be saved. You might walk the tree writing out
// information on each object as you come to it, or as in this case
// just get a bunch of art and work in batch mode. It depends on what your doing.

error = WriteText( pathName, message->fileFormat == this->fFileFormatSelected );
}

else if ( message->option & kFileFormatRead )
{
AIRealPoint origin;
sAIDocument->GetDocumentRulerOrigin(&origin);
std::cout << "Document origin " << origin.h << "," << origin.v << std::endl;
AIRealRect maxbounds;
sAIDocument->GetDocumentMaxArtboardBounds(&maxbounds);
std::cout << "Max artboard bounds " << maxbounds.left << "," << maxbounds.bottom << " " << (maxbounds.right-maxbounds.left) << "x" << (maxbounds.top-maxbounds.bottom) << std::endl;
ai::ArtboardList artboardList;
sAIArtboard->GetArtboardList(artboardList);
ai::ArtboardProperties artboardProperties;
AIRealRect artBounds;
artBounds.left = -500;
artBounds.bottom = -500;
artBounds.right = 500;
artBounds.top = 500;
error = artboardProperties.SetPosition(artBounds);
if (kNoErr == error)
std::cout << "Artboard bounds ok" << std::endl;
else
std::cout << "Failed to set artboard bounds" << std::endl;
error = ReadText( pathName );
}

return error;
}

Sorry I didn't see your previous comment when I posted my last reply.

When I said "random", I should have said unpredictable. You always get the same offset for the same "/artboard" preference setting but it is hard to work out the relationship.

The "AIDocumentCanvasSize" key value is 16383 and it has no effect if I delete this before calling GetDocumentMaxArtboardBounds.

Reverting AIArtboard::SetPosition was just a suggestion. I don't mind how you fix it as long as I can create artboards without errors.

Thank you for the time you have spent on this issue.

"it seems to be fairly random".
Then it occurs this is some uninitialized value in dictionary which is being read during this custom file open logic. As I mentioned earlier please undefine the given key in dictionary in you plugin prior to querying max size.

I understand your concern with the change in behavior of SetPosition api with cc2018. Reverting that change is not a solution since the problem you are mentioned is in GetDocumentMaxArtboardBounds api which is independent of SetPosition api.
You may try GetDocumentMaxArtboardBounds api even on earlier version and the behavior should be consistent with current version of sdk.

The offset is not the document ruler origin, it is RELATIVE TO the ruler origin. As I said it seems to be fairly random and is affected by the "/artboard" setting (even though this is just a size).

Note also that I don't think the behaviour of the AIDocument::GetDocumentMaxArtboardBounds function has changed with CC 2018. The problem is that the result of this function is now used to determine if an artboard is valid, whereas before it was not used. So one fix would be to revert the behaviour of AIArtboard::SetPosition so that it doesn't check the result of AIDocument::GetDocumentMaxArtboardBounds.

Thank you

Maybe there is some faulty entry in artwork dictionary which is not yet updated during read in your custom file-format plugin.
Can you try deleting the following entry from document dictionary in your code prior to calling GetDocumentMaxArtboardBounds.

Key: "AIDocumentCanvasSize"

/** Removes the entry with a given key from a dictionary.
@param dict The dictionary.
@param key The key object.
*/
AIAPI AIErr (*DeleteEntry) ( AIDictionaryRef dictionary, AIDictKey key );

Offset must be the document ruler origin, which is generally not on top-left but somewhere around the center of canvas.

From documentation:

/** Retrieves the maximum valid bounds of any artboard, expressed relative to
the ruler origin of the current document, *regardless of the current
size of the document's artboard*.
@param bounds [out] A buffer in which to return the rectangle,
*/
AIAPI AIErr (*GetDocumentMaxArtboardBounds)( AIRealRect *bounds );

Yes I am using the latest SDK.

Please look into why the AIDocument::GetDocumentMaxArtboardBounds function is affected by the user preference. If this is fixed then I think it will solve the problem.

Note that the bounds include an offset as well as a size. I don't know where the offset comes from. It seems to be fairly random and can stop the plugin even creating artboards that are smaller than the "/artboard" setting if they are outside the bounds.

Thank you

1. What is the "/artboard" setting in the user preferences intended for?
Ans: As quickly I can see, it just holds the preference for the artboard dimension which will be loaded on Cmnd-Alt-N. And that is decided on the basis of initial artboard size chosen while Cmnd-N or a default 792*612. It has nothing to do with canvas/ doc size.

2. Why does the "/artboard" setting affect the result of the AIDocument::GetDocumentMaxArtboardBounds SDK function?
Ans: Ideally it should not as I can understand from api name. This needs to be verified though if this is happening. I hope you are working with latest sdk.

3. How can a plugin create a 750x750 px artboard, when the user's "/artboard" setting is smaller?
Ans: If (2) is resolved then (3)is NA.

Hello Shivendra

Thank you for your comment.

The problem occurs creating artboards in an Illustrator plugin that registers its own file format for reading. It is not an issue with users creating their own artboards.

The plugin calls AIArtboard::SetPosition to specify the size and position of the artboard it wants to create. This returns an error if the artboard bounds are outside the bounds returned by the AIDocument::GetDocumentMaxArtboardBounds function.. The problem is that the bounds returned by AIDocument::GetDocumentMaxArtboardBounds are not 16383*16383 px, but seem to depend on what kind of documents a user has been working with.

When I said "one who uses small documents and one who uses large documents" I was talking about the size of the artboards they were using.

There is an "/artboard" setting in the user preferences file which is affected by the size of the artboards the user has been using. This setting in turn affects the bounds returned by AIDocument::GetDocumentMaxArtboardBounds.

Example

User A has been using artboards that are 500x500 px, so this is stored in his "/artboard" preference. He tries to open a file using our plugin that wants to create a 750x750 px artboard. This fails because the artboard is bigger than his "/artboard" setting.

User B has been using artboards that are 1000x1000px. He tries to open the same file using our plugin and it works because his "/artboard" setting is larger.

Please can you answer these questions:

What is the "/artboard" setting in the user preferences intended for?
Why does the "/artboard" setting affect the result of the AIDocument::GetDocumentMaxArtboardBounds SDK function?
How can a plugin create a 750x750 px artboard, when the user's "/artboard" setting is smaller?

Thank you

Hello Patrick,

The change in CC2018 was to restrict the Artboards within the Canvas/ Document bounds which are safe to work by design. Each canvas is of fixed size i.e. 16383*16383 px.

From your statement: "one who uses small documents and one who uses large documents"
I am not sure what you mean by different doc size as what I understand, canvas/ doc size can never be different than 16383*16383 px..

We expect users to utilize this max doc size only for their workflows. In case there was some data that was lying outside earlier, it will still open correctly but should be brought in within canvas boundaries in new versions of illustrator for further modifications.