• P (unregistered)

    Isn't this just hand unrolling loops? Clearly they didn't unroll it enough, let's add a few more for good measure.

  • bvs23bkv33 (unregistered)

    New Comment();

  • (nodebb)

    The breaks are wrong anyway; you want each break on or before the 80th character after the previous break, not on or before the 80th, 161st, 242nd, 323rd characters. Except the code says 343, so that's twice as wrong...

  • scragar (unregistered) in reply to urkerab

    It's one more because they inserted a new line so it's 80 characters before line break + 1 character for the line break + 80 characters after the line break.

    The funny thing is they're still wrong even if they got the 323 correct because they should be testing based on the last break + 80 characters + 1 line break. As it currently is if you break at 75 characters in and insert a line break as character 76 you don't want the new endpoint to be 161 character in, that allows for an 85 character line.

  • Jay (unregistered)

    If the block has more than 8 newlines, parse it in chunks of 80 characters, else parse it in chunks of 65 characters. In each chunk, add a newline before the last word.

    There are several problems:

    1. They should have used a loop and a set of counters. As it stands, if they receive a file with more than 400 characters, they will miss one or more split sites.

    2. They could have used an array and split on their character index. My guess is that they output is read line by line outside of this block

    3. The branch's last condition splits on character 343 instead of 323. This is either a typo, or the there's a maximum length of 340 characters in the initial input

    Judging by how they use the last space character in a chunk as the split, either they're working with multiple formats or there's a better pattern to match on.

  • Jay (unregistered)

    Additionally, it's hard to say what they expect from the output. If they get a raw 340 character block without any spaces, they won't get any splits. Is that still valid? This code works in that it won't crash outside of the character limit of 340, but the results will only guarantee lines of 340 characters or less.

  • Jay (unregistered)

    I get it now. They're trying to do a word-wrap with varying sized blobs of text. if there are 8 or more lines, wrap every 80 characters, else wrap every 65 characters.

  • (nodebb)

    Probably actually a better choice than what I did the last time I was making a bunch of Win32 MeasureText calls. Snot as easy as it would seem.

  • b.a. freeman (unregistered)

    since they can apparently break lines pretty much any place they want, why not read in the entire text of the label, stripping out the newlines, and inserting your own where necessary? it would be a lot cleaner.

  • Really? (unregistered)

    I'm surprised no one has mentioned that they should just be replacing the spaces with newlines instead of doing extra math to account for inserted spaces. Less memory manipulation and a cleaner loop.

    As mentioned, it'd be better to have something to break apart lines of 80+ characters with no spaces too. There it makes sense to insert, just update the index going into the next loop by 2, one for the hyphen and one for the newline.

  • (nodebb)

    Dump the source text into any text editor that soft- or hard-wraps lines for you, then use the API that you hope the editor has to get the new text back. (I'm willing to bet NP++ will actually let you do something that crazy)

  • theres your problem (unregistered)

    Did Remy miss the reason this code only “works most of the time”? See that 'If String.IsNullOrEmpty(result) Then result = line'? When 'line' is empty, it clears 'result' removing anything from previous iterations of the For Each loop.

  • Really? (unregistered) in reply to theres your problem

    While I applaud you for checking that, as I just skimmed over it before, you may want to look again. The null/empty check and assignment are both to result. It will only be 'cleared' if it was already empty.

    That said, it was assigned the empty string to begin with, so it should never be null, so the if/else is pointless.

  • (nodebb)

    It is probably a bad sign, that the wtfs seem increasingly harmless to me...

  • Anonymous (unregistered)

    There might be in fact an off by one error. If thi code runs on Windows Environment.NewLine is \r\n which are actually two character. So the string grows by two and not one character, each time a break is inserted.

  • Fernando (unregistered)

    Speaking of unreadable code: no matter how wide I make my browser window, the code display refuses to widen enough to remove the horizontal scrollbar at its bottom. I see big wide margins surrounding code that I can read only by moving down to the scrollbar, shifting it right, moving up to the line of code, reading it, moving down to the scrollbar, shifting it left ... SMH.

  • NoLand (unregistered)

    /(.{80})/$1\n/g

  • Raj (unregistered) in reply to cellocgw

    I second the NP++ design. Also it seems we're more due than for a DIY WTF competition. Maybe this time the challenge could be to build an AI solution that works at least as poorly as Watson.

  • (nodebb) in reply to scragar

    This gets better the farther apart the spaces are. Indices 3 and 160? One 157 character line coming right up.

    And of course, this totally breaks for even longer segments without any spaces, where this would just insert a whole lot of line breaks before the first character. But I assume the input data is guaranteed (or quasi-guaranteed) to contain lots of spaces, so in practice this should not break too often.

  • (nodebb)

    I have had the 'pleasure' of working on one of these label printer systems: Crafted in Borland C++ Builder 5.0, using the circa 2000 proposed features (mostly setter/getter attributes) of C++ that ended up landing in C#.

    The underlying problem is that label printer machine manufacturers seem to think that their printers will just be used to create millions of fixed labels with a barcode and an incrementing serial number and date stamp. Their label designing software is generally horrible and requires downloading templates to printers with the same amount of memory as an old BBC micro..

    In this case the only thing fixed about the label was the size of the medium we were printing on. ..

    The label printer implemented a 'compiler' and an 'interpreter' for a sort of machine language describing operations that gradually created a bitmap which could be sent to a label.

    Different countries administrations demanded different label layouts, different products demanded different content.

    The fitting text to space was made more fun by using proportionally spaced fonts..

    First prize for chaos in this went to a huge 'general.cpp' file, about 50000 lines long. It compiled down to a DLL , and had to be all one file because Borland decided that the class name must match the base name of the source file that contained it, a hangover from Delphi.. Essentially this was a runtime library performing many unrelated tasks. Alongside it were about 50 source files for different countries plugin DLLs each describing business rules and exceptions to label layouts. And hundreds of 'compiled' label layouts.

    In the end I wrote a parser using YACC and LEX and converted all the label creation logic into Lua code, and we then wrote a 'label graphics' library in C++ bound to Lua.

    Another application consisted of a C# .NET DLL linked to VB6 to keep an old application alive when Windows security models changed.

  • MiserableOldGit (unregistered)

    Presumably the maximum size of the label is a physical limit that can't be changed at all, let alone automagickly? And so if the text to go in it won't fit then some user will have to frig around with abbreviations until it does. Wouldn't be the first time I've been told that's how things are going to work when I've enquired about edge cases.
    So it might be a bit of a shonky solution, but it works and without knowing what the organisation expected/asked to happen in the case of too much data it's hard to get too excited.
    TRWTF is ERPs, home-grown ones doubly so.

  • Quirkafleeg (unregistered)

    Not a WTF - it is precisely what I would expect from a VB developer :) TRWTF is writing an ERP system in VB in the first place :D

Leave a comment on “Break your Labels”

Log In or post as a guest

Replying to comment #513020:

« Return to Article