Can you post your code?

I notice there is lot of looping and grouping going on. Any chance it is related? If you output the "bcText" at each step (inside the pdf) is the value correct? Also, for grins you might output the image URL and confirm whether it is repeating, or the "bcText" is repeating.

jeff.c wrote:

 

Not sure it's helpful, but here's the code, at least the relevant parts.  As I said, I've confirmed that this is all doing what it's supposed to and if I take off the cfdocument, it renders to the screen perfectly every time.

 

<cfdocument format="PDF" pagewidth="4" pageheight="6.0" pagetype="CUSTOM" margintop="0.17" marginbottom="0.05" marginleft="0.17" marginright="0.17">

 

<cfset labelCounter = 1 />

<cfoutput query="qryGetShippingLabelData" group="Lab_Code">

  <!--- Do some stuff --->

  <cfoutput group="shipGroup">

    <cfloop from=1 to=#numLabels# index="i">

      <cfset bcText = "" />

      <cfif labelCounter NEQ 1><cfdocumentitem type="pagebreak" /></cfif>

      #labelHead#

      <cfoutput>

        <cfset bcText = bcText & numberFormat(study_id,"00000") & iif(singleSampleBox,1,numSamples) />

      </cfoutput>

                              <cfset bcText = numberFormat(Lab_ID,"00000") & bcText />

                              <p><cfimage action="writeToBrowser" source="#getCode128(bcText)#" /></p>

      #labelFoot#

      <cfset labelCounter = labelCounter + 1 />

    </cfloop>

  </cfoutput>

</cfoutput>

 

</cfdocument>

The code needs improving. The PDF may render correctly after that, who knows.

1) You have, at the centre of it all, code that is within 3 loops. It will help to scope the variables, such as qryGetShippingLabelData.x and shipGroup.y.

2) The cfouput tag in the following stretch is unnecessarily in the way:

      <cfoutput>

        <cfset bcText = bcText & numberFormat(study_id,"00000") & iif(singleSampleBox,1,numSamples) />

      </cfoutput>

Then again, if you drop this cfoutput tag you will get:

<cfset bcText = bcText & numberFormat(study_id,"00000") & iif(singleSampleBox,1,numSamples) />

<cfset bcText = numberFormat(Lab_ID,"00000") & bcText />

That looks like repetition to me. At least, it doesn't appear to me that that was the intention.

          function getCode128 (data)           {

               barcode = bbq.createCode128(data);

               barcode.setBarWidth( 1 );

After seeing the function code, first thing I would recommend is VAR scoping all of the function local variables. Then try it again.

-==cfSearching==- wrote:

 

          function getCode128 (data)           {

               barcode = bbq.createCode128(data);

               barcode.setBarWidth( 1 );

After seeing the function code, first thing I would recommend is VAR scoping all of the function local variables. Then try it again.

In fact, I would VAR newImg and barcodeImage as well.

-==cfSearching==- wrote:

 

In fact, I would VAR newImg and barcodeImage as well.

 

Yep, that is why I said all function local variables. I was only trying to highlight the fact that were no VAR scope declarations at the top of the function. (I did not look over the  variable names in detail :-)

Nice of you, but you needn't explain. It was an oversight. I was already thinking VAR myself, and so just skimmed 'barcode' and 'VAR'. Sorry.

@BKBK: I don't want to sidetrack the thread here, but that last statement about assuming the order of processing on a list in the CFLOOP tag is pretty concerning. I've never witnessed any behavior other than processing the list exactly in the order provided, and I have a hard time believing that we've just been lucky for 15 years. That /is/ in fact a key assumption in lots of CFML code. Do you have a basis for that statement, either in the docs or repeatable behavior in code you can share? To have them processed in anything other than the order provided seems so counterintuitive as to render the whole concept of using a list to drive any sort of iteration as basically useless...

--

/ron

jeff.c sent me a copy of his code and image files referenced above, and I have duplicated this behavior on a fully-updated 9.01 box. Same exact behavior, so it is clearly not something unique to 8.01 or something that has been patched in 9.x. I have a CF10 box I will try this on in a bit, as well...

Update: also does not work on CF10 beta -- same behavior.

--

/ron

(Update:  Grr... I just love this forum software.)

I think I was finally able to reproduce the behavior on 9.01. But it only happens when setDrawingText(..) is false.

<cfscript>

    /* deliberately refactored to eliminate  var scoping issues as a possible cause */

    function getCode128 ( data, hideText )           {

        var bbq = createObject("java", "net.sourceforge.barbecue.BarcodeFactory");

        var ih = createObject("java", "net.sourceforge.barbecue.BarcodeImageHandler");

        var barcode = bbq.createCode128( arguments.data );

        barcode.setBarWidth( 1 );

        barcode.setBarHeight( 50 );

        barcode.setDrawingQuietSection( false );

        barcode.setResolution( 200 );

        if ( structKeyExists(arguments, "hideText") and arguments.hideText ) {

            barcode.setDrawingText( false );

        }

        return ImageNew(ih.getImage( barcode ));

    }

</cfscript>

<cfset numbers = ["00413001811","00403001811","00413001811","00403001811"] />

<cfdocument format="pdf">

    <cfloop from="1" to="#arrayLen(numbers)#" index="i">

        <cfset imgText  = numbers[i] />

        <cfset hideText = i lte 2 />

        <cfoutput>

           [#i#] #imgText# <cfimage action="writetobrowser" source="#getCode128(imgText, hideText)#" /><br />

        </cfoutput>

    </cfloop>

</cfdocument>

jeff.c wrote:

maybe at least an acknowledgement from an Adobe rep that there may be an issue here?

Well these are user-to-user forums. If you want to speak with an adobe representative, you need to use official channels. (While I have seen an occaisional comment here and there, it is rare. So it is extremely unlikely you would get a response from an Adobe employee here).

Message was edited by: -==cfSearching==-

I'm not comfortable just including the barcode text though and hoping

that it

solves the problem.  In my mind, it's still possible and likely

that the underlying

engine could still be confused in comparing images

We are on the same page there. I would not rely on it either. It just helps illustrate the issue a bit more clearly.

-Leigh

jeff.c wrote:

 

@BKBK - Your test would validate my hypothesis that cfdocument is doing something to look at the images and determine if they have already been loaded and, if so, reuse the already loaded image.  Whatever that comparison is based on is treating these two images as the same image.  Since you've altered the original image, I'm not surprised that it now works correctly, but if you go back to the original images, unaltered, I'm quite confident you'll see the same behavior.  For what it's worth, I compared the MD5 sum of the two images and they do not match.

Your confidence is justified! I reran my above test with the original image. I did reproduce the issue.

Leigh, you might want to change the text rendered red in your code to quoted strings.

Yes, you are right but that is courtesy of this lovely forum software ;-). After it mangled the original (with quotes) three times, I finally gave up. I am not sure it lets you edit posts after other responses are added. I will check the web interface later.

I am still running into this issue in cf 9.01 as well..... so frustrating to have to use lossy jpegs to render my bar codes into a pdf.

Thanks for incredible troubleshooting and follow up Jeff, you are my hero.