MarcEditor Changes and Right-to-left displays

By reeset / On / In character encodings, MarcEdit

So, this was a tough one.  MarcEdit has a right-to-left data entry mode that was created primary for users that are creating bibliographic records primarily in a right to left language.  But what happens when you are mixing data in a record from left-to-right languages like English and Right-to-left languages, like Hebrew.  Well, in the display, odd things happen.  This is because of what the operating system does when rendering the data.  The operating system assumes certain data belongs to the right-to-left string, and then moves data in a way that it think it should render.  Here’s an example:

In this example, the $a$0 are displayed side-by-side, but this is just a display issue.  Underneath, the data is really correct.  If you compiled this data or loaded into an ILS, the data would parse correctly (though, how it displayed would be up to the ILS support of the language).  But this is confusing, but unfortunately, one of the challenges of working with records in a notepad-like environment.

Now, there is a solution that can solve the display problem.  There are two Unicode characters 0x200E and 0x200F — these are Left-to-right character markers and Right-to-left character markers.  These can be embedded in the display to render characters more appropriately.  They only show up in the display (i.e. are added when reading into the display), and are not preserved in the MARC record.  They help to alleviate some of these problems.


The way that this works — when the program identifies that its working with UTF8 data, the program will screen the text for characters have a byte that indicate that they should be rendered RTL.  The program will then embed a RTL marker at the beginning of the string and a LTR marker at the end of the string.  This gives the operating system instructions as to how to render the data, and I believe helps to solve this issue.




MarcEdit and Alma Integration: Working with holdings data

By reeset / On / In Cataloging, MarcEdit

Ok Alma folks,

 I’ve been thinking about a way to integrate holdings editing into the Alma integration work with MarcEdit.  Alma handles holdings via MFHDs, but honestly, the process for getting to holdings data seems a little quirky to me.  Let me explain.  When working with bibliographic data, the workflow to extract records for edit and then update, looks like the following:


  1. Records are queried via Z39.50 or SRU
  2. Data can be extracted directly to MarcEdit for editing



  1. Data is saved, and then turned into MARCXML
  2. If the record has an ID, I have to query a specific API to retrieve specific data that will be part of the bib object
  3. Data is assembled in MARCXML, and then updated or created.


Essentially, an update or create takes 2 API calls.

For holdings, it’s a much different animal.


  1. Search via Z39.50/SRU
  2. Query the Bib API to retrieve the holdings link
  3. Query the holdings link api to retrieve a list of holding ids
  4. Query each holdings record API individually to retrieve a holdings object
  5. Convert the holdings object to MARCXML and then into a form editable in the MarcEditor
    1. As part of this process, I have to embed the bib_id and holdin_id into the record (I’m using a 999 field) so that I can do the update


For Update/Create

  1. Convert the data to MARCXML
  2. Extract the ids and reassemble the records
  3. Post via the update or create API


Extracting the data for edit is a real pain.  I’m not sure why so many calls are necessary to pull the data.

 Anyway – Let me give you an idea of the process I’m setting up.

First – you query the data:

Couple things to note – to pull holdings, you have to click on the download all holdings link, or right click on the item you want to download.  Or, select the items you want to download, and then select CTRL+H.

When you select the option, the program will prompt you to ask if you want it to create a new holdings record if one doesn’t exist. 


The program will then either download all the associated holdings records or create a new one.

Couple things I want you to notice about these records.  There is a 999 field added, and you’ll notice that I’ve created this in MarcEdit.  Here’s the problem…I need to retain the BIB number to attach the holdings record to (it’s not in the holdings object), and I need the holdings record number (again, not in the holdings object).  This is a required field in MarcEdit’s process.  I can tell if a holdings item is new or updated by the presence or lack of the $d. 


Anyway – this is the process that I’ve come up with…it seems to work.  I’ve got a lot of debugging code to remove because I was having some trouble with the Alma API responses and needed to see what was happening underneath.  Anyway, if you are an Alma user, I’d be curious if this process looks like it will work.  Anyway, as I say – I have some cleanup left to do before anyone can use this, but I think that I’m getting close.



Truncating a field by a # of words in MarcEdit

By reeset / On / In Cataloging, MarcEdit

This question came up on the listserv, and I thought that it might be generically useful that other folks might find it interesting.  Here’s the question:

I’d like to limit the length of the 520 summary fields to a maximum of 100 words and adding the punctuation “…” at the end. Anyone have a good process/regex for doing this?
=520  \\$aNew York Times Bestseller Award-winning and New York Times bestselling author Laura Lippman’s Tess Monaghan—first introduced in the classic Baltimore Blues—must protect an up-and-coming Hollywood actress, but when murder strikes on a TV set, the unflappable PI discovers everyone’s got a secret. {esc}(S2{esc}(B[A] welcome addition to Tess Monaghan’s adventures and an insightful look at the desperation that drives those grasping for a shot at fame and those who will do anything to keep it.{esc}(S3{esc}(B—San Francisco Chronicle When private investigator Tess Monaghan literally runs into the crew of the fledgling TV series Mann of Steel while sculling, she expects sharp words and evil looks, not an assignment. But the company has been plagued by a series of disturbing incidents since its arrival on location in Baltimore: bad press, union threats, and small, costly on-set “accidents” that have wreaked havoc with its shooting schedule. As a result, Mann’s creator, Flip Tumulty, the son of a Hollywood legend, is worried for the safety of his young female lead, Selene Waites, and asks Tess to serve as her bodyguard. Tumulty’s concern may be well founded. Recently, a Baltimore man was discovered dead in his home, surrounded by photos of the beautiful—if difficult—aspiring star. In the past, Tess has had enough trouble guarding her own body. Keeping a spoiled movie princess under wraps may be more than she can handle since Selene is not as naive as everyone seems to think, and instead is quite devious. Once Tess gets a taste of this world of make-believe—with their vanities, their self-serving agendas, and their remarkably skewed visions of reality—she’s just about ready to throw in the towel. But she’s pulled back in when a grisly on-set murder occurs, threatening to topple the wall of secrets surrounding Mann of Steel as lives, dreams, and careers are scattered among the ruins.
So, there isn’t really a true expression that can break on number of words, in part, because how we define word boundaries will vary between different languages.  Likewise, the MARC formatting can cause a challenge.  So, the best approach is to look for good enough – and in this case, good enough is likely breaking on spaces.  My suggestion is to look for 100 spaces, and then truncate.
In MarcEdit, this is easiest to do using the Replace function.  The expression would look like the following:
Find: (=520.{4})(\$a)(?<words>([^ ]*\s){100})(.*)
Replace: $1$2${words}…
Check the use regular expressions option. (image below).
So why does this work.  Let’s break it down.
(=520.{4}) – this matches the field number, the two spaces related to the mnemonic format, and then the two indicator values.
(\$a) – this matches on the subfield a
(?<words>([^ ]*\s){100}) – this is where the magic happens.  You’ll notice two things about this.   First, I use a nested expression, and second, I name one.  Why do I do that?  Well, the reason is because the group numbering gets wonky once you start nesting expressions.  In those cases, it’s easier to name them.  So, in this case, I’ve named the group that I want to retrieve, and then have created a subgroup that matches on characters that aren’t a space, and then a space.  I then use the qualifier {100}, which means, must match at least 100 times.
(.*) — match the rest of the field.
Now when we do the replace, putting the field back together is really easy.  We know we want to reprint the field number, the subfield code, and then the group that captured the 100 units.  Since we named the 100 units, we call that directly by name.  Hence,
$1 — prints out =520  \\
$2 — $a
${words} — prints 100 words
… — the literals
And that’s it.  Pretty easy if you know what you are looking for.

MarcEdit Update Notes

By reeset / On / In BibFrame, MarcEdit

MarcEdit Update: All Versions

Over the past several weeks, I’ve been working on a wide range of updates related to MarcEdit. Some of these updates have dealt with how MarcEdit handles interactions with other systems, some of these updates have dealt with integrating the new bibframe processing into the toolkit, and some of these updates have been related to adding more functionality around the programs terminal programs and SRU support. In all, this is a significant update that required the addition of ~20k lines of code to the Windows version, and almost 3x that to the MacOs version (as I was adding SRU support). In all, I think the updates provide substantial benefit. The updates completed were as follows:


* Enhancement: SRU Support — added SRU support to the Z39.50 Client
* Enhancement: Z39.50/SRU import: Direct import from the MarcEditor
* Enhancement: Alma/Koha integration: SRU Support
* Enhancement: Alma Integration: All code needed to add Holdings editing has been completed; TODO: UI work.
* Enhancement: Validator: MacOS was using older code — updated to match Windows/Linux code (i.e., moved away from original custom code to the shared validator.dll library)
* Enhancement: MARCNext: Bibframe2 Profile added
* Enhancement: BibFrame2 conversion added to the terminal
* Enhancement: Unhandled Exception Handling: MacOS handles exceptions differently — I created a new unhandled exception handler to make it so that if there is an application error that causes a crash, you receive good information about what caused it.

Couple of specific notes about changes in the Mac Update.

Validation – the Mac program was using an older set of code that handled validation. The code wasn’t incorrect, but it was out of date. At some point, I’d consolidated the validation code into its own namespace and hadn’t updated these changes on the Mac side. This was unfortunate. Anyway, I spent time updating the process so the all versions now share the same code and will receive updates at the same pace.

SRU Support – I’m not how I missed adding SRU support to the Mac version, but I had. So, while I was updating ILS integrations to support SRU when available, I added SRU support to the MacOS.

BibFrame2 Support – One of the things I was never able to get working in MarcEdit’s Mac version was the Bibframe XQuery code. There were some issues with how URI paths resolved in the .NET version of Saxon. Fortunately, the new bibframe2 tools don’t have this issue, so I’ve been able to add them to the application. You will find the new option under the MARCNext area or via the command-line.


* Enhancement: Alma/Koha integration: SRU Support
* Enhancement: MARCNext: Bibframe2 Profile added
* Enhancement: Terminal: Bibframe2 conversion added to the terminal.
* Enhancement: Alma Integration: All code needed to add Holdings editing has been completed; TODO: UI work.
Windows changes were specifically related to integrations and bibframe2 support. On the integrations side, I enabled SRU support when available and wrote a good deal of code to support holdings record manipulation in Alma. I’ll be exposing this functionality through the UI shortly. On the bibframe front, I added the ability to convert data using either the bibframe2 or bibframe1 profiles. Bibframe2 is obviously the default.

With both updates, I made significant changes to the Terminal and wrote up some new documentation. You can find the documentation, and information on how to leverage the terminal versions of MarcEdit at this location: The MarcEdit Field Guide: Working with MarcEdit’s command-line tools

Downloads can be picked up through the automated updating tool or from the downloads page at:

MarcEdit Update (all versions); post-mortem analysis of the website (continued) downtime

By reeset / On / In MarcEdit

*** Update: as of 11:10 AM EST, 3/6/2017 — it appears all resources are back online and available.  Much thanks to Darryl, a helpful support agent that found whatever magic setting that was keeping the DNS from refreshing. ***


What a long weekend this has been.  If you are a MarcEdit user, you are probably aware that since late Thursday (around 11 pm EST), the MarcEdit website has shifted between being up, down, to currently (as of writing) completely disappeared.  I have Bluehost to thank for that; though more on that below.  More importantly, if you are a MarcEdit user, you may have found yourself having problems with the application.  On Windows, if you have plugins installed, you will find that the program starts, and then quits.  On a Mac, if you have automatic updates enabled or plugins installed, you see the same thing…the program starts, and then quits.  I’ve received a lot of email about this (+2k as of right now), and have answered a number of questions individually, via the listserv (on Friday) and via Twitter – but generally, this whole past couple of days has been a real pain in the ass.  So, let’s start with the most important thing that folks want to know – how do you get past the crashing.  Well, you have a couple of options.

Update MarcEdit

I know, I know – how can you update MarcEdit when the MarcEdit website isn’t resolving.  Well, the website is there – what isn’t resolving is the DNS (more on why below).  The MarcEdit website is a subdomain on my primary domain,  It points to a folder on that domain, and that folder is still there, and can be accessed directly via the direct path to the file (rather than though the dedicated dns entry).  So, where can you get them?  Directly, the links to the files are as follows:

You can see the change logs for each of these versions, if you access the links directly:

My hope, is that sometime between 12 am – 8 am 3/6/2017; the DNS entry will reset and will come back to life.  If it does, the problems folks are having with MarcEdit will resolve themselves, users will be prompted to download the referred updates above, and I can put this unpleasantness behind me.  However, I will admit that my confidence in my webhost is a little shaken, so I’m not confident that everything will be back to normal by morning – and if it isn’t; the links above should get users to the update that will correct the issues that we are seeing.

Disabling AutoChecking

If you are in a position where you cannot update MarcEdit using one of the links above, and the website has not come back up yet – you will need to take a couple of steps to keep the automatic checks from running and causing the unhandled exception.  I’ve noted this on the listserv, but I’ll document the process here:

  • On Windows:
    The process that is causing the crash is the plugin autochecking code.  This code will only run if you have installed a plugin.  To disable autochecking, you will want to remove your plugins.  The easiest way to do that is to go to your User Application folder, find the plugins directory, and do one of two things: 1) delete your plugins (assuming you’ll just put them back later) or 2) rename the plugin folder to plugin.bak and create an empty plugins folder.  The next time you restart MarcEdit – it should function normally.  You will be able to re-enable your plugins when MarcEdit’s website comes back up; but the only permanent solution will be to update your version of MarcEdit.
  • On MacOS:
    The process that is causing the crash is the plugin autochecking and the application autochecking.  You will need to disable the parts that apply to you.  As with the Windows instructions – this is a temporary measure – the permanent fix would be to update MarcEdit using the website (if is live), or directly using one of the links above.
    Disable autoupdate: You will need to open the config.xml file in the application user directory.  This is found on a MacOs system at: /Users/your_user_name/marcedit/configs – open the config.xml file.  Find the <settings></settings> XML block.  You are looking for the <autoupdate> element.  If it’s not present, autoupdating is automatically enabled.  Add the following snipped into the <settings> block.  <autoupdate>0</autoupdate>  This will disable automatic update checking.
    Disable plugin checking: You will find the plugins folder (assuming you’ve downloaded a plugin) in the application user space.  This is found at: /Users/your_user_name/marcedit/plugins – as with the Windows instructions, either delete the contents of the folder, or rename the folder as plugins.bak and create a new empty folder in its place.  Doing those two steps will disable the automatic checking, and allow you to use MarcEdit normally.

So what the hell happened?

Well, there are two answers to this question – and it was the convergence of these two issues that caused the current unpleasantness.

On the MarcEdit-side

I really wish that I could say that this was all on my webhost, but I can’t.  MarcEdit is a large, complicated application, and in order to keep it running well, the tool has to do a lot of housekeeping and data validation.  To ensure that all these tasks don’t cause the application to grind to a halt – I thread these processes.  Generally, with each function that falls into their own separate thread, I include a try{…}catch{…}finally{…} block to handle exceptions that might popup.  Additionally, I have an exception handler that handles errors that fall outside of these blocks – they protect the program from crashing.  So, what happened here?  The problem is the threading.  By running these functions in their own threads, they fall outside of MarcEdit’s global exception handler.  This is why it is important that each of these thread blocks have their own exception handling, and that it be very good.  And, for whatever reason, I didn’t provide explicit handling of connection issues in the checkplugins code.  This is why the website being down has impacted the program.

On the Website side

I have used Bluehost as my website provider for years.  They have been a trusted partner and while I’ve had the occasional blip, this is the first time that I can honest say that I’ve felt like they’ve completely dropped the ball.  The problem here, started with a planned server update.  Bluehost notified me that there would be a brief period of inconsistent access while they updated some server components.  This is routine stuff, and should have amounted to no more than a few minutes of downtime.  I host my website on their cloud infrastructure, which is distributed across multiple nodes – I figured no big deal, this is exactly what a cloud infrastructure was designed for – if they have a problem at one data center – you just enable access through another one.  Well, that’s not how it happened.  When I got up on Friday, there was an ominous, and cryptic message from Bluehost letting me that there was some trouble with the update, and they would be restoring access to service throughout the day.  Why did this affect all the nodes?  What actually happened?  Who knows.  All I know is that all Friday, all content was inaccessible and contacting Bluehost was impossible.  When things didn’t come back up by 7 pm EST, I stayed on hold for 4 hours before giving up and hoping things would look better in the morning.

Saturday morning…things didn’t look better.  Access to the administrative dashboard had been restored, but the database server was inaccessible and all subdomains were broken.  I finally got ahold of support around noon, after waiting on hold for another 3 hours – and they filed a ticket, and asked me to check back in an hour because they were going to reset the DNS.  By Saturday evening, the database server was alive again, my second hosted domain was at least visible, but the other subdomains still didn’t work.  I waited on hold again for another 2 hours, and got a hold of another person from support.  This time, we talked about what I was seeing in my DNS record and the Subdomain editing tools.  Things weren’t right.  They said they would file another ticket, I thanked them, and went to bed.

Sunday morning – things are moving in the right direction.  All content on the domain is accessible, the blog is accessible, and the secondary domain mostly works.  My other subdomains have all disappeared.  I contacted support again – they re-established the subdomains, manually edited the dns record…and this is where we stand. At this point, I believe that once the DNS propagates, the last of my subdomains (include will become live again.  At least that is my hope.  I’m really, really, really hoping that I don’t have to take this up with support again.

As I noted above, this is the first time that I can honestly say, I have been really unhappy with the way Bluehost has handled the outage.  These things happen (they shouldn’t), but I understand it.  I work in IT, I’ve been in the position that they are in now; but I find that the best course of action is to own it, and communicate with your customers proactively, and often.  What has disappointed me the most from Bluehost has been the blackhole of information.  Unless I contact support, they aren’t saying anything – and their front line support has no way to check the status of my tickets because they were escalated to their internal support units.  So, I’m basically just twittling my thumbs until someone finally decided to let me know what’s going on, or things just start working.

In Summary

So, to summarize – there is a fix, and you can access it at the links above or you can disable the offending code by following the instructions above.  When will the website be live, your guess is as good as mine at this point, but hopefully soon.  Long-term; I have a github account that I use to host code, and have setup a page at: to host information about those projects.  Given the pain this has caused, I will likely invest some time in setting up a mirror of the domain over there; so that if something comes up, I users can still get access to the resources that they need to work.

If you have questions, feel free to let me know.


MarcEdit Mac Update

By reeset / On / In MarcEdit

It seems like I’ve been making a lot of progress wrapping up some of the last major features missing from the Mac version of MarcEdit.  The previous update introduced support for custom/user defined fonts and font sizes which I hope went a long way towards solving accessibility issues.  Today’s update brings plugin support to MarcEdit Mac.  This version integrates the plugin manager and provides a new set of templates for interacting with the program.  Additionally, I’ve migrated one of the Windows plugins (Internet Archive to HathiTrust Packager) to the new framework.  Once the program is updated, you’ll have access to the current plugins.  I have 3 that I’d like to migrate, and will likely be doing some work over the next few weeks to make that happen.

Interested in seeing what the plugin support looks like? See:

You can download the file from the downloads page ( or via the automatic updating tool in the program.

Questions?  Let me know.


MarcEdit Update: All Versions

By reeset / On / In MarcEdit

All versions have been updated.  For specific information about workstream work, please see: MarcEdit Workstreams: MacOS and Windows/Linux

MarcEdit Mac Changelog:

** 2.2.35
* Bug Fix: Delimited Text Translator: The 3rd delimiter wasn’t being set reliably. This should be corrected.
* Enhancement: Accessibility: Users can now change the font and font sizes in the application.
* Enhancement: Delimited Text Translator: Users can enter position and length on all fields.

MarcEdit Windows/Linux Changelog:

* Enhancement: Plugin management: automated updates, support for 3rd party plugins, and better plugin management has been added.
* Bug Fix: Delimited Text Translator: The 3rd delimiter wasn’t being set reliably. This should be corrected.
* Update: Field Count: Field count has been updated to improve counting when dealing with formatting issues.
* Enhancement: Delimited Text Translator: Users can enter position and length on all fields.

Downloads are available via the automated updating tool or via the Downloads ( page.



MarcEdit KBart Plugin

By reeset / On / In MarcEdit

Last year, I had the opportunity to present at NASIG, and one of the questions that came up was related to the KBart format and if MarcEdit could generate it.  I’ll be honest, I’d never heard of KBart and this was the first time it had come up.  Well, fast forward a few months and I’ve heard the name a few more times, and since I’ll be making my way to NASIG again later this year to speak, I figured this time I’d come bearing new gifts.  So, I spent about 20 minutes this evening wrapping up a kbart plugin.  The interface is very basic:

And essentially has been designed to allow a user to take a MARC or MarcEdit mnemonic file and output a kbart file in either tab or comma delimited format.

Now, a couple of caveats — I still don’t really have a great idea of why folks want to create kbart files — this isn’t my area.  But the documentation on the working group’s website was straightforward, so I believe that the files generated will be up to par.  Though, I’m hoping that prior to NASIG, a few of the folks that may actually find something like this interesting may be willing to give it a spin and provide a little feedback.

Again, this will be available after the next update is posted so that I can allow it to take advantage of some of the new plugin management features being added to the tool.


MarcEdit Workstreams: MacOS and Windows/Linux

By reeset / On / In MarcEdit

Over the past couple of months, I’ve had some interesting questions that have been leading me to going back and relooking at how a handful of things work within MarcEdit.  To that end, I’m hoping to complete the following two workstreams this weekend.


Two of the features most often asked for at this point deal with accessibility options and plugin support.  The creation of the AddPinyin plugin for windows ( has got people asking if this will show up for Mac Users as well.  My guess is that it could, but in order for that to happen, I need to implement plugin support in the Mac.  The challenge is figuring out how, since the process I used with Windows and Linux simply won’t work with the Mac UI thread model.  So, I’ve been thinking on this, and this weekend, I’ll be including the first parts of code that should allow me to start making this happen.  Ideally, I’ll start by migrating some of the current MarcEdit plugins, probably the Internet Archive 2 HathiTrust Packager first; and then go from there.

The other change that I’m working on that will show up in this update is the ability to control the application font and font sizes.  You can see the start of this work here:  Like the windows version, I’ll eventually add language support, which will enable the use of language files to set the text in the application.  But for now, I’ll be enabling the ability to modify the application font and change the size of the fonts within the application and editor.


The interest in the plugins have made me take another look at how they are managed.  Currently it is clunky, users get no notification when they change, and updating them takes multiple steps.  That will change.  I’ve been restructuring how plugins are managed, so that they will now automatically notify users when they have changed, as well as offer the ability to download the update.  Additionally, I’ve extended the plugin manager so that it can manage access to plugins outside of the MarcEdit website, so I’ll be including links to the AddPinyin plugin, and be able to include this plugin in the automated management (i.e., update notification).  Overall, I believe that this will make plugins easier to use, and much, much easier to manage.


MarcEdit MacOS Updates

By reeset / On / In MarcEdit

This past weekend, I spent a good deal of time getting the MacOS version of MarcEdit synchronized with the Windows and Linux builds.  In addition to the updates, there is a significant change to the program that needs to be noted as well. 

First, let’s start with the changelog.  The following changes were made in this version:

** 2.2.30
* Bug Fix: Delimited Text Translator — when receiving Unix formatted files on Windows, the program may struggle with determining new line data.  This has been corrected.
* Bug Fix: RDA Helper — when processing copyright information, there are occasions where the output can create double brackets ($c[[) — this should be corrected.
* Behavior Change: Delimited Text Translator — I’ve changed the default value from on to off as it applies to ignoring header rows. 
* Enhancement: System Info (main window) — I’ve added information related to referenced libraries to help with debugging questions.
* Bug fix/Behavior Change: Export Tab Delimited Records: Second delimiter insertion should be standardized with all regressions removed.
* New Feature: Linked Data Tools: Service Status options have been included so users can check the status of the currently profiled linked data services.
* New Feature: Preferences/Networked Tasks: MarcEdit uses a short timeout (0.03 seconds) when determining if a network is available.  I’ve had reports of folks using MarcEdit have their network dropped from MarcEdit.  This is likely because their network has more latency.  In the preferences, you can modify this value.  I would never set it above 500 milliseconds (0.05 seconds) because it will cause MarcEdit to freeze when off network, but this will give users more control over their network interactions.
* Bug Fix: Swap Field Function: The new enhancement in the swap field function added with the last update didn’t work in all cases.  This should close that gap.
* Enhancement: Export Tab Delimited Records: Added Configurable third delimiter.
* Enhancement: MarcEditor: Improvements in the Page Counting to better support invalid formatted data.
* Enhancement: Extract/Delete MARC Records: Added file open button to make it easier to select file for batch search
* Bug Fix: Log File locking and inaccessible till closed in very specific instances.
* Enhancement: Compiling changes…For the first time, I’ve been able to compile as 64-bit, which has reduced download size.
* Bug Fix: Deduplicate Records: The program would thrown an error if the dedup save file was left blank.

Application Architecture Changes

The first thing that I wanted to highlight is that the program is being built as a 64-bit application.  This is a significant change to the program.  Since the program was ported to MacOS, the program has been compiled as a 32-bit application.  This has been necessary due to some of the requirements found in the mono stack.  However, over the past year, Microsoft has become very involved in this space (primarily to make it easier to develop IOS applications on Windows via an emulator), and that has lead to the ability to compile MarcEdit as a 64-bit application. 

So why do this if the 32-bit version worked?  Well, what spurred this on was a conversation that I had with the homebrew maintainers.  It appears that they are removing the universal compilation options which will break Z39.50 support in MarcEdit.  They suggested making my own tap (which I will likely pursue), but it got me spending time seeing what dependencies were keeping me from compiling directly to 64-bit.  It took some doing, but I believe that I’ve gotten all code that necessitated building as 32-bit out of the application, and the build is passing and working. 

I’m pointing this out because I could have missed something.  My tools for automated testing for the MacOS build are pretty non-existent.  So, if you run into a problem, please let me know.  Also, as a consequence of compiling only to 64-bit, I’ve been able to reduce the size of the download significantly because I am able to reduce the number of dependencies that I needed to link to.  This download should be roughly 38 MB smaller than previous versions.

Downloading the Update

You can download the update using the automated download prompt in MarcEdit or by going to the downloads page at: