Skip to content
This repository has been archived by the owner on Jan 29, 2019. It is now read-only.

Data type for internal representation of code128 encoded values #1

Open
wants to merge 16 commits into
base: master
Choose a base branch
from
Open

Data type for internal representation of code128 encoded values #1

wants to merge 16 commits into from

Conversation

glfmn
Copy link
Member

@glfmn glfmn commented Jun 22, 2017

Implement Code128 barcode representation as underlying type for our visual encoding system, allowing us to fall back to regular bar-code scanning if we have issues with our custom format.

Rationale

Code128, as described by Wikipedia, is a high-density barcode data encoding format, which uses patterns to represent symbols in 3 different symbologies which cover different ranges of the ASCII standard.

The Code128 type is essentially intended to encapsulate conversion between many different representations of Code128 barcodes, especially between bit patterns (such as {0,0,0,1,1,1,0,0,1}) or associated weight patterns (such as {3,3,2,1}) and strings.

ToDo

  • Checksum validation
  • Conversion from Code128 to string
  • Conversion from string to Code128
  • Conversion from bit pattern to Code128
  • Conversion from weight pattern to Code128
  • Robust error handling using Result<T,E> specialization
  • Stable external API for Code128 module

Gwen Lofman added 5 commits June 22, 2017 12:34
Working checksum digit calculation and validation with basic tests
covering hard-coded cases, pending a more complete solution.
Change module-level documentation to block-comment style for easier
line reading, and change `From<u8>` to use stop code as wild-card
conversion to catch all unxpectd values.

Add variant documentation for `Symbology` enum, and fix values;
stop codes had associated start code values shifted by one.
Better seperation between tests and base module, allows easier
definition of macros or functions used only in the tests.
Simply panics if it recieves an unexpected value, and does not
implement shift-codes.

Uses a rudimentary finite state machine to model the change in
behavior for each symbology, pushing characters symbol-per-symbol
to build the encoded string.
Preferable to use iterators and expression-based for loop to avoid
carying arround an extra mutable value and manually manipulating
indecies.
@glfmn glfmn self-assigned this Jun 22, 2017
@glfmn glfmn changed the title Data code128 barcode Data type for internal representation and validation of code128 barcode Jun 22, 2017
@glfmn glfmn changed the title Data type for internal representation and validation of code128 barcode Data type for internal representation of code128 encoded data Jun 22, 2017
@glfmn glfmn changed the title Data type for internal representation of code128 encoded data Data type for internal representation of code128 encoded values Jun 22, 2017
Gwen Lofman added 4 commits June 23, 2017 12:05
`to_string` implies an implementation of `Display` or `ToString`
for the type, so to disambiguate the method is now called `decode`

I am considering an `Into` implementation, but since the conversion
may fail if the checksum digit fails, `TryInto` would be a better
option.  However, since `TryInto` is only in Nightly, that decision
is pushed down the road.
Improves ability for error handling, as the possible values are now
constrained more strictly for each symbol, making impossible states
impossible to represent.  Deriving PartialOrd and Ord make it easy
to keep the exact same behaviour as before, replacing only the u8
literals with Pattern literals.
Rather than just matching on possible symbologies, also match on
shift codes to perform shift-code specific behaviour.
@glfmn
Copy link
Member Author

glfmn commented Jun 30, 2017

Consider using traits to encapsulate encode and decode behaviour, so that we can support both standard UFT-8 strings, C-Strings, and perhaps even other types like Vec<u8> or bitvector which might encode barcode data.

A sufficiently general conversion API should be able to convert directly from any one supported encoding to another.

Gwen Lofman added 2 commits July 9, 2017 02:31
Allows for module to be public for integration and benchmark
testing while making it clear that the contained modules are not
meant for normal module users.
May end up making things take a long time, consider removing in the
future if it causes problems.
@glfmn glfmn added this to the 0.1 milestone Jul 20, 2017
Gwen Lofman added 5 commits July 22, 2017 00:49
Generic over formats, allowing support for decoding a variety of
barcode types to a variety of target types, and encoding to formats
from a variety of types.

The ultimate purpose is to allow conversions to rust strings and c
strings in the future, and to support the direct conversion of
arbitrary encoding types directly to a supported Decode type (for
a given format).
Use `Encoding` trait to represent different encoding types,
starting with `u8` and `Pattern`.

Use u8 in doc tests where appropriate.
Benchmark testing allows me to check for performance regressions and
make performance improvements over time.  Essential for having real
time capability.
Better description of what the module actually does, as it mainly
encapsulates all of the barcode logic.
Since I was using u8 to perform the actual string conversions
anyway, simply use u8 directly and remove the repr() method from
Encoding trait.

Saves about 100 ns/iter on benchmarks.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant