PDF supports a concept of pattern fills, where you first define the appearance of a "tile" of the pattern, and then define the region to be filled by repeating that tile.
MicroGDS uses this mechanism for symbol and hatch fills, because it reduces the size of PDF files considerably, because the tile only has to be written to the file once. The alternative would be to redraw the pattern each time it appears in the filled area, which would both take longer and produce larger (perhaps much larger) PDF files.
Unfortunately, there's a bug or misfeature in Adobe Reader which means that, when the drawing contains both such a pattern filled area and a transparent filled area, Adobe Reader's Print command can take a long time, use a lot of memory, and generate a very large printer spool file. Adobe Reader typically displays a message Flattening: nn% for long periods while printing such a file.
A consequence of these problems is that the print may fail entirely if the memory or disk space required exceeds that available, or if the user's patience gives out before the print has completed. We have reported this problem to Adobe, but have heard nothing from them in reply.
Fortunately, this only seems to happen when the fill pattern is extremely detailed, such as repeating every 0.1mm on the paper -- too detailed to be visible in the final print, and probably a mistake. In every case we have seen so far, redefining the fill linestyle to more reasonable values has cured the problem.
We might consider providing a "don't use pattern fill" option on the PDF export dialog, as a workround, but we are reluctant because (a) the best fix is probably to correct one of the linestyle definitions, (b) we hope the Adobe will fix the underlying problem, and (c) because the resulting very large PDF files may not be acceptable anyway.
Another possible workround is to generate the PDF using a print driver (either that supplied with Adobe Acrobat, or a third party solution such as pdf995, cutepdf or pdffactory). This has the effect of not using PDF's pattern fill, resulting in larger PDF files, but it also seems not to provoke the bug/misfeature in Adobe Reader. Such PDF files tend to be unsatisfactory in other respects too.