docRef.Export bugs?

[Peter JD Matthews]

I seem to have found two bugs in docRef.Export for jpg in CS4.

I found in posting this that the period marks (full stops) in the filename strings were almost invisible. Since these are crucual to the point I have enclosed then in {} like this "{.}"

1. Poor quality jpg exports irrespective of the  QualitySetting value.

2. The documentation tells you to supply the file path with no extension - it will be supplied. However Export clearly has a function to strip off the extension should you have left it on. This then is antagonistic to legal windows (7 in my case) file names, since these allow multiple periods in the file name, only the text after the last period being considered the extension. The Export function function strips off everything after any period there is in the filename and then adds jpg.

So a file  XYZ{.}ABC{.}ai - which we want to generate XYZ{.}ABC{.}jpg should be supplied as XYZ{.}ABC acording to the documentation - but if this is done the return is XYZ{.}jpg. If XYZ{.}ABC{.}ai is supplied then it gets even stranger, and I am not sure of all the ramifications, but filenames like XYZ{.}AbC abc{.}ai generated output names like XYZ{.}ABC -abc{.}jpg - note the added "-"!

I suggest the function should either assume the filename fed it is correct and just add the ".jpg" or the documentation should be changed to require the extension to remain, and the function should strip off the text after the last period and append "jpg".

Any comments / workarounds?

[moluapple]

How about export with regular name, and rename filename after export.

[Peter JD Matthews]

Moluapple,

Thanks for the reply. I am not sure what you mean by the "regular name"? I

can see the possibility of exporting with a fixed simple 'fake' name and

then renaming, and agree that whilst annoying this could work. (and it would

be proof against Adobe fixing this bug). However the quality issue has to be

resolved as well or this function is dead in the water.

BTW - all this in code that has worked fine for many years and iterations of

illo versions, and has just crashed in the last few weeks!

[Muppet_Mark-phjQ9l]

When you say quality are you refering to the applied compression or the fact that it's always 72dip as for the export I have always supplied full file path as parameter… You may need to post some code?

[Peter JD Matthews]

Thanks to you both.

Re the quality, I will have to do some checking and get back. I realise that

all I can really say is that for hundreds of uses over many years the jpeg

quality has been acceptable, and very recently it is not. Quality has always

been set at 100. However since the quality was acceptable I had never

thought about what the quality parameter meant. Of course a manual output

gives control over both resolution and the compression factor. Since you say

the resolution has always been fixed at 72 dpi (for goodness sake, 'Why"?!)

maybe I had always been looking in the past at reduced versions - i.e. drawn

full page and then viewed at around 3"*3" - giving an effective dpi of

around 200. Maybe - that's what I need to look at. I take it there is

absolutely no way of improving the dpi output?

Re the file name issue - I think the 'fake name' solution is as good as it

is going to get thanks.

Peter

[Muppet_Mark-phjQ9l]

The AI way is to output at 72dpi and allow you to scale H&V… I don't recall anyone posting who prefers it this way about…? but there you go… I don't understand what you are saying about export naming though?

[Peter JD Matthews]

Muppet Mark,

A further example perhaps? I have effectively got (ignoring quotes and & and

stuff - remember this code has worked hundreds of times over many years - I

am just trying to focus on essentials.)

docRef. Export pm0909.01CP fig4.5.jpg

what I get is "pm0909.01CP -fig4.5.jpg"

Or am I missing your point?

Peter

[Muppet_Mark-phjQ9l]

What I am saying is… In javaScript… exportFile (exportFile: File, exportFormat: ExportType[, options: any]) 3 parameters…

var jpegOpts = new ExportOptionsJPEG();
jpegOpts.antiAliasing = true; 
jpegOpts.qualitySetting = 100;   
jpegOpts.optimization = true;
jpegOpts.horizontalScale = 100;
jpegOpts.verticalScale = 100;
jpegOpts.artBoardClipping = true;
var jpegPath = File( dF.fsName+'/'+baseName+'_'+abName+'.jpeg' );
docRef.exportFile( jpegPath, ExportType.JPEG, jpegOpts );

[Peter JD Matthews]

Esentially the same code - only vba. Currently I have -

Dim jpegExportOptions As New Illustrator.ExportOptionsJPEG

                jpegExportOptions.Optimization = False  ' do not optimise for web

                jpegExportOptions.AntiAliasing = True

                jpegExportOptions.QualitySetting = 70

                jpegExportOptions.HorizontalScale = 300

                jpegExportOptions.VerticalScale = 300

                strFileName4Export = strBasePath & "\" & "ExportedFileName"

                Call docRef.Export(strFileName4Export, aiJPEG, jpegExportOptions)

...

Dim strRealName As String

                    strRealName = strBasePath & "\" & strFigName & ".jpg"

                    Name strFileName4Export & ".jpg" As strRealName

Note that I now have a fixed Export file name ("ExportedFileName") to get round the problem oulined in my earlier mails. (Per moluapple's sugestion). Previously the Export line would have contained the variable strFigName in its place and produced the problems I have described

Also note that I have introduced a fixed scaling (300) to improve the resolution. However this bulks up the file size and what I would like to do is to use a calculated scale factor based on the size of the actual illustration - not the paper / artboard size, but the overal dimensions of what has been drawn. I have been though the scripting manual and there are many instances of, for example, "height" but they all apear to apply to individual constructs within the drawing. Do any of them in fact define the veral size of what is drawn?

[Muppet_Mark-phjQ9l]

You should probably make the first artboards rectangle the same as the documents visible bounds ( if theres only one ) or do the math off each artboards rectangle to caluclate sizes… Never seen this issue of file naming before so my guess it is VB related?

[Peter JD Matthews]

I have never taken any notice of artboards before so I had to do some research on this. Looking at a couple of my examples the artboard is just the same size as the page. Looking in the manual and help I can only see how to manually resize the artboard, so when you say  "make the first artboards rectangle the same as the documents visible bounds" I assume you mean to do this manually before running the script? I had hoped for some means of automatically finding the size of the drawing, but perhaps this is not available. I appreciate the thought though.

Re the filename bug - yes it may be a VB thing. However note this code has been in place for years, and all the filenames it handled over that time have multiple periods in them, and many have spaces as well. I cannot say with any great precision when this bug first happened, but it was probably within the last three months. Are you sure you have used this function with the 'difficult' filenames in that period?

[moluapple]

exporting with a fixed simple 'fake' name and
then renaming

Yes, that's what I mean, I haven't test this issue through.